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1 1 K I :  I  AC I 

This  guidebook  is  one  oi  a  series  of  guidebooks  intended  to  assist 
the  Air  Firce  Program  Office  and  engineering  personnel  in  soitware  acquisition 
engineering  for  airborne  systems.  The  contents  of  the  guidebooks  wilj  be 
revised  periodically  to  reflect  changes  in  soitware  acquisition  policies 
and  practices  and  feedback  from  users. 

This  guidebook  has  been  prepared  under  the  direction  of  the 
Aeronautical  Systems  Division  (ASD)  ,  Deputy  for  engineering  (EN),  in 
coordination  with  the  Space  and  Missile  Systems  Organization  (SAMSO), 

Airforce  Systems  Command  (Al SC) . 

The  series  of  Software  Acquisition  engineering  Cuidebooks  (Air¬ 
borne  Systems)  is  currently  planned  to  cover  the  following  topics: 

Available  Guidebooks 


•  Regulations,  Specifications  and  Standards,  ASD-TR-78-b;  ADA058428 

•  Software  Quality  Assurance,  ASD- TR- 78-8;  ADA0S90b8 

•  Reviews  and  Audits,  ASD-TR- 78- 7;  A DADS 84 29 

•  Statements  of  Work  and  Kequists  for  Proposal,  ASD- TR- 79- 502b 

•  Configuration  Management,  ASD-TR- 79-5024 

•  Computer  Program  Documentation  Requirements,  ASD-TR- 79-5025 
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1.  INTRODUCTION 


1  .  1  PURPOSE  AND  SCOPE 

The  purpose  of  this  guidebook  is  to  provide  Air  Force  Program 
Office  engineering  and  management  personnel  with  information  that  will 
help  them  prepare  Requests  for  Proposal  (RFP's)  for  acquisition  of 
software  embedded  in  weapon  systems.  While  this  guidebook  is  oriented 
primarily  toward  procurements  required  under  AFR  70-15  and  AFR  800-2, 
its  concepts  and  procedures,  appropriately  tailored,  are  recommended  for 
lower-dollar  and  less  complex  procurements. 

This  guidebook  describes  the  structure  and  function  of  thevSOW  and 
RFP  with  special  emphasis  on  software  acquisition  under  the  AFR  800- 
series  of  Air  Force  regulations  (See  Section  4.  1  of  the  Regulations , 
Specifications,  and  Standards  (RSS)  Guidebook).  It  provides  methods  for 
defining  the  elements  of  a  SOW  and  a  method  of  organizing  them.  This 
guidebook  also  presents  methods  for  RFP  preparation  with  emphasis  on 
making  it  a  clear,  concise,  communicative  instrument  for  expressing  the 
requirements  to  the  prospective  software  developer.  Preparation  of  the 
Statement  of  Work  (SOW)  portion  of  the  RFP  is  given  special  attention. 

The  SOW/RFP  preparation  is  presented  in  context  with  the  proc  ure¬ 
ment  process  as  summarized  below; 

1.  Identification  of  an  acquisition  through  the  system 
acquisition  planning  process. 

2.  Appointment  of  a  working  level  manager  responsible 
for  the  entire  source  selection  and  formation  of  a  team 
by  appropriate  disciplines  to  refine  the  planning  and 
develop  an  RFP. 

3.  Establishment  of  milestones  for  the  acquisition.  One 
of  the  first  milestones  is  formation  of  a  Business 
Strategy  Panel  (See  AFSCR  70-2). 

4.  Division  of  the  team  by  the  working  level  manager  into 
areas,  of  expertise,  with  "team  chiefs"  responsible  for 
the  Techn:cal,  Management,  and  Cost  sections  of  the 
RFP.  This  manager  must  coordinate  the  development 
of  each  of  the  RFP  sections  to  ensure  source  selection 
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milestones  are  met.  He  must  support  each  team  chief 
in  obtaining  key  team  members  for  the  various  disci¬ 
plines.  For  example,  the  Technical  Area  Chief  will 
need  assistance  in  his  areas  of  responsibility,  such  as 
the  specifications,  SOW,  CDRL,  proposal  preparation 
instructions,  evaluation  factors  for  award,  and  the 
program  office  independent  cost  estimate.  The  follow¬ 
ing  staff  personnel  support  the  Team  Chiefs.  A  Data 
Manager  would  go  through  a  Data  Call  and  develop  a 
Contract  Data  Requirements  List  (CDRL).  Financial 
personnel  would  help  develop  independent  cost  estimates. 
Procurement  personnel  would  oversee  business  consid¬ 
erations,  develop  special  provisions,  etc. 

5.  Production  of  a  Draft  RFP,  following  several  iterations 

of  the  team's  efforts,  for  release  to  industry  for  comment. 

6.  Incorporation  of  industry  comments  to  the  DRFP  and 
submittal  of  RFP  including  Sections  A  through  M  of  the 
Uniform  Contract  Format  (UCF)  to  a  Procurement 
Evaluation  Panel  (Murder  Board;  see  AFSCR  70-7). 

7.  Incorporation  of  Murder  Board  comments. 

8.  Release  of  the  RFP  to  the  procurement  staff  for  final 
release  approval. 

9.  Receipt  and  evaluation  of  proposals  and  award  of 
contracts  in  accordance  with  AFR  70-15. 

Procurements  under  the  AFR  300-series  of  Air  Force  regulations 
is  briefly  discussed  in  Section  4.2  of  the  RSS  Guidebook. 

1.2  CONTEXT  OF  RFP  AND  SOW 


The  RFP  is  one  of  the  most  important  documents  in  the  acquisition 
cycle.  All  of  the  preparation  and  planning  for  a  procurement  goes  into 
the  RFP  as  the  key  communication  to  potential  contractors  on  exactly 
what,  how,  and  when  the  Government  needs  to  buy.  If  the  RFP  does  not 
fulfill  this  primary  purpose  -  communication  -  the  best  planning  may 
be  upset.  The  basic  message  is  elementary  -  the  RFP  must  be  complete, 
concise  and  a  clear  communication  of  Government  requirements. 

An  RFP  is  used  to  solicit  proposals  for  required  supplies  and 
services  from  industry.  A  good  contract  provides  for  a  fair  exchange 
by  the  contractor  and  the  Government  of  something  of  value  by  each  part. 


It  must  accurately  reflect  a  "meeting  of  minds.  "  Thus  the  contract  must 
include  a  proper  definition  and  description  of  what  is  to  be  exchanged, 
and  how  the  exchange  will  be  effected.  A  clear,  concise,  and  complete 
RFP  that  will  foster  meaningful  negotiations  is  the  basis  for  the  contract. 
Anything  less  makes  a  good  contract  difficult  to  achieve. 

The  RFP  must  be  organized  and  prepared  in  four  parts  in  accordance 
with  ASPR  3-501.  RFP  Part  I  (Sections  A  through  D)  is  not  included  in 
the  contract.  It  is  in  the  RFP  to  provide  instructions  for  proposal  pre¬ 
paration.  RFP  Parts  II,  III  and  IV  (Sections  E  through  M)  along  with 
RFP  Attachments  and  Exhibits  (if  used)  are  included  in  the  contract 
after  possible  change  during  contract  negotiations.  A  top  level  view 
of  the  typical  contract  structure  for  deliverable  computer  programs  is 
shown  in  Figure  1-1. 

Other  parts  of  the  RFP  of  particular  software  relevance  are  the 
delivery  schedule  (Section  H),  inspection  and  acceptance  (Section  I), 
special  provisions  (Section  J ) ,  general  provisions  (Section  L),  the 
Contract  Data  Requirements  List  (attachment  or  exhibit)  and  the  specifi¬ 
cations  (attachments). 

RFPs  for  different  development  phases  in  the  Major  Defense  System 
Acquisition  Life  Cycle  have  few  variations  except  in  the  firmness  of  the 
specifications  included  in  the  RFP.  Table  1-1  indicates  the  progressive 
strengthening  of  major  RFP-included  specifications  through  the  acquisi¬ 
tion  life  cycle.  See  Section  5.4.3.  1. 

Section  4.  1  below  presents,  for  the  weapon  system  life  cycle,  the 
pha  se  -  related  guidelines  for  SOW/RFP  preparation.  Generally,  contracts 
are  written  for  one  phase.  Options  for  follow-ons  should  not  be  binding 
so  that  the  Air  Force  could  drop  a  contractor  after  the  first  phase  because 
of  poor  performance.  Phase  2  may  be  included  in  the  bid  package  to: 

1)  minimize  cost  and  schedule  impacts  caused  by  changing  contractors, 
and  2)  obtain  cost  estimates  to  support  program  reviews  for  the  next 
life  cycle  phases. 
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SECTION  H 


Table  1-1.  Typical  Specifications  Included  in  the  RFP 
for  each  Acquisition  Phase 


Specifications 

Conceptual 

Phase 

Validation 

Phase 

Full-Scale 

Engineering 

Development 

Phase 

Production 
and  Deploy¬ 
ment  Phases 

System 

Requirements 

Documents 

X 

Initial  System 
Spec 

X 

Authenticated 
System  Spec 

X 

X 

T  echnical 
Requirements 
Document  for 
the  CPCI 

X 

CPCI 

P  r  elimina  ry 

Part  I  Spec 

X 

CPCI  Part  I 

Spec 

X 

X 

1 

CPCI  Part  II 
Spec 

1 

x 

1 

i 

1.2.2  RFP/SOVV  Within  the  Guidebook  Series 


This  guidebook  addresses  the  following  guidebooks  in  specifying 
and  contracting  for  the  work  to  be  done: 

•  "Regulations,  Specification,  and  Standards "  (RSS)  for 

1)  government  requirements  on  RFP/SOW  preparation, 

2)  use  of  RSS  documents  as  compliance  documents,  and 

3)  defining  CDRL  items; 

•  "Software  Quality  Assurance"  for  guidelines  in  imposing 
QA  requirements  in  the  SOW; 
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Reviews  and  Audits"  for  definition  and  incorporation  of 


d 


evelopment  Milestones; 


•  "Contracting  for  Software  Acquisition"  for  1)  determining 
the  type  of  contract  and  options,  2)  developing  evaluation 
factors  for  contract  award,  and  3)  consummating  the 
RFP/SOW  package  into  a  contract; 

•  "Verification,  Validation  and  Certification"  for  develop- 
ment  of  related  CCiRL  items; 

•  "Configuration  Management"  (CM)  for  preparation  of  the 
SOW  task  on  CM; 


•  "  Requirements  Analysis  and  Specification"  for  developing  the 

software  specification;  and  "Computer  Program  Documentation" 
for  determining  the  deliverable  documentation  via  the  CDRL. 


1.3  CONTENTS  OF  THE  GUIDEBOOK 


This  guidebook  contains  the  following  parts: 

•  Section  1,  Introduction.  This  section  contains  the  purpose 
and  scope  of  this  guidebook,  states  the  general  functions  of 
the  RFP  and  SOW  and  outlines  the  content  of  this  guidebook. 

•  Section  2,  Applicable  Documents.  This  section  references 
documents  relevant  to  RFP  and  SOW  preparation. 

•  Section  3,  Guidelines  for  SOW  Preparation.  This  section 
discusses  general  guidelines,  SOW  organization,  planning 
of  SOW  preparation  task,  WBS,  SOW  composition,  data 
management,  a  SOW  writer's  checklist  and  SOW  develop¬ 
ment  steps. 

•  Section  4,  SOW  Phase  and  Discipline  Specific  Guidelines. 

This  section  discusses  the  SOW  related  to  the  acquisition 
life  cycle,  types  of  SOW  tasks,  and  variables  affecting  the 
SOW  content. 

•  Section  5,  Guidelines  for  RFP  Preparation.  This  section  dis¬ 
cusses  responsibilities,  RFP  organization,  events  and  schedules, 
and  RFP  content  with  emphasis  on  software- related  items. 

Maximum  use  of  references  is  made  since  it  keeps  the  guidebook 
current  as  the  references  are  modified. 
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2.  REFERENCE  DOCUMENTS 


The  Software  Acquisition  Engineering  Guidebook  on  Regulations, 
Specifications  and  Standards  lists  and  provides  abstracts  of  all  current 
government  documents  which  specify  or  provide  additional  guidance  on 
Statements  of  Work  and  Requests  for  Proposal  and  related  disciplines. 


The  primary  documents  which  are 

1.  DOD  5000.  19-L, 

Vol  II 

2.  DODD  5000.1 

3.  DODD  5000.2 

4.  DODD  5000.29 

5.  MIL-S-52779  (AD) 

6.  MIL-S-83490 

7.  MIL-STD-480* 

8.  MIL-STD-481 

9.  MIL-STD-482A 

10.  MIL-STD-483 
(USAF ) 

11.  MIL-STD-490 

12.  MIL -STD -881 A 


particularly  relevant  are: 

Acquisition  Management  Systems  and 
Data  Requirements  Control  List 

Major  System  Acquisitions 

Major  System  Acquisition  Process 

Management  of  Computer  Resources 
in  Major  Defense  Systems 

Software  Quality  Assurance  Program 
Requirements 

Specifications,  Types  and  Forms 

Configuration  Control  -  Engineering 
Changes,  Deviations  and  Waivers 

Configuration  Control  -  Engineering 
Changes,  Deviations  and  Waivers 
(Short  Form) 

Configuration  Status  Accounting  Data 
Elements  and  Related  Features 

Configuration  Management  Practices 
for  Systems,  Equipment,  Munitions 
and  Computer  Programs 

Specification  Practices 

Work  Breakdown  Structures  for 
Defense  Materiel  Items 


*MIL-STD-480  is  expected  to  be  replaced  by  DOD-STD-480A. 


13.  MIL-STD-1521A 
(USAF) 

Technical  Reviews  and  Audits  for 
Systems,  Equipment,  and  Computer 
Programs 

14.  AFR  70-15 

Source  Selection  Policy 

15.  AFR  122-9 

The  Nuclear  Safety  Crosscheck 
Analysis  and  Certification  Program 
for  Weapon  Systems  Software 

16.  AFR  122-10 

Nuclear  Weapon  Systems  Safety 

Design  and  Evaluation  Criteria 

17.  AFR  300-10 

Computer  Programming  Languages 

18.  AFR  310-1 

Management  of  Contractor  Data 

19.  AFR  800-2 

Acquisition  Management  -  Program 
Management 

20.  AFR  800-14, 

Vol  I 

Management  of  Computer  Resources 
in  Systems 

21.  AFR  800-14, 

Vol  II 

Acquisition  and  Support  Procedures 
for  Computer  Resources  in  Systems 

22.  AFR  800-25 

Specification  and  Standards  Application 

23.  AFSCR  70-2 

AFSC  Business  Strategy  Panel 

24.  AFSCR  70-7 

Procurement  Evaluation  Panel 

25.  AFSCR  80-15 

R&D  Source  Selection  Policy  and 
Guidance 

26.  AFSCR  310-1 

Management  of  Contractor  Data 

27.  AFSCR  310-2 

Deferred  Requisitioning  of 

Engineering  Data 

28.  AFSCM  173-4 

Program  Breakdown  Structures 
and  Codes 

29.  AFSCP  70-4 ^ 

Request  for  Proposal  Preparation 

Guide 

30.  AFSCP  800-3 

A  Guide  to  Program  Management 

T 


In  the  preparation  of  this  guidebook,  extensive  information  has  been 
obtained  from  these  documents. 


Acquisition  Management  -  Statement 
of  Work  Preparation  Guide 


31.  AFSCP  800-6  ^ 

32.  SAMSOR  70-2  f 

33.  SAMSOP  800-6  f 

34.  SAMSO-STD-73-3 

35.  MTR-3194t 

36.  ASPR 


Request  for  Proposal  Policy 

Acquisition  Management  -  Statement 
of  Work  Preparation 

Standard  Engineering  Practices  for 
Computer  Software  Design  and 
Development 

^3-^  Air  Force  Guide  to  Software- 
Related  SOW  Preparation  by  the 
MITRE  Corp. 

Armed  Services  Procurement 
Regulations 


In  the  preparation  of  this  guidebook, 
obtained  from  these  documents. 


extensive  information  has  been 


3.  GUIDELINES  FOR  SOW  PREPARATION 


3.1  GENERAL 

The  SOW  is  an  amplification  of  Section  E  of  both  the  RFP  and  the 
contract.  It  is  prepared  when  the  task  requirements  and  related  infor¬ 
mation  are  too  lengthy  to  be  conveniently  written  into  Section  E.  The 
SOW  is  included  as  an  attachment  to  both  the  RFP  and  the  contract. 

The  SOW  describes  the  work  which  the  Government  wants  accom¬ 
plished  by  the  contractor,  identifies  the  products  of  each  task,  relies 
on  the  Contract  Data  Requirements  List  (CDRL)  to  establish  form,  con¬ 
tent  and  delivery  requirements  for  data,  and  is  consistent  with  both  the 
preliminary  Contract  Work  Breakdown  Structure  (CWBS)  and  the  program 
objectives  identified  in  the  Program  Management  Directive.  Responsi¬ 
bilities  for  SOW  preparation  are  contained  in  AFSCP  800-6.  This  guide¬ 
book  interprets  these  objectives,  states  general  requirements  for  SOW 
preparation,  and  suggests  actions  helpful  to  the  preparation  of  a  good  SOW. 

3.2  SOW  ORGANIZATION 

The  SOW  is  organized  differently  depending  on  the  acquisition  phase 
and  type  of  effort.  These  formats  are  presented  in  AFSCP  800-6, 

Chapters  3  through  8.  Section  4  presents  some  SOW  variations  with 
phases.  A  typical  full-scale  engineering  development  (FSED)  phase  SOW 
outline  is  shown  in  Figure  3-1. 

3.3  GETTING  STARTED 

The  SOW  must  be  consistent  with  the  requirements  levied  on 
offerors  in  other  parts  of  the  RFP,  such  as  Sections  C,  D,  the  CDRL, 
and  the  specifications.  Therefore,  the  team  that  prepares  the  SOW  will 
work  on  these  other  sections  as  well.  This  manager  must  coordinate  the 
development  of  each  of  the  RFP  sections  to  ensure  source  selection  mile¬ 
stones  are  met. 

While  it  is  impractical  to  attempt  to  provide  guidance  covering  all 
eventualities  in  preparation  of  SOW's,  the  succeeding  paragraphs  will 
provide  general  guidance  on  how  to  begin.  The  person  assigned  the 
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1. 

SCOPE  AND  OBJECTIVES 

2. 

GENERAL  BACKGROUND 

(Information,  constraints,  and  reference  documents) 

3. 

CONTRACTOR  TASKS 

3.  1 

COMPLIANCE  DOCUMENTS 

3.2 

DESIGN  AND  DEVELOPMENT  OF  SYSTEM 

3.3 

TRAINING 

3.4 

DESIGN  AND  DEVELOPMENT  OF  OPERATIONAL 

SUPPORT  EQUIPMENT 

3.5 

DESIGN,  DEVELOPMENT,  TEST  AND  EVALUATION  OF 

PECULIAR  SUPPORT  EQUIPMENT 

3.6 

SYSTEM  TEST  AND  EVALUATION 

3.7 

SYSTEM/PROJECT  MANAGEMENT 

3.8 

OVERALL  DATA  REQUIREMENTS 

(Technical  Orders,  Manuals,  and  Management  Data) 

3.9 

OPERATIONAL/SITE  ACTIVATION 

4. 

SPECIAL  CONSIDERATIONS 

ANNEX  TO  SOW 

1. 

COMPUTER  PROGRAMMING  PRODUCTS 
(e.g.,  DI-E-30145) 

Figure  3-1.  Typical  FSED  Phase  SOW  Outline 

responsibility  for  preparing  a  SOW  should  follow  these  steps  to  get 
started : 

•  St e p  1 .  Review  the  requirement  and  directive  documents 
which  authorized  the  program  and  defined  its  basic 
objectives,  e.  g.  ,  PMD,  PMP,  DCP,  APP,  ROC. 

•  St e p  2  .  Review  the  Air  Force  and  AFSC  regulations,  policy 
directives,  etc.,  which  apply  to  the  type  of  procurement 
under  consideration.  Prepare  a  bibliography  citing  the 
regulatory  material  which  should  be  used  in  preparing  the 
SOW. 
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•  Step  3.  Obtain  copies  of  the  preliminary  system  specification 
or  lower  level  specifications,  or  similar  technical  require¬ 
ments  documents  to  be  referenced  in  the  SOW. 

•  Step  4.  Obtain  copies  of  the  Program  Breakdown  Structure  (PBS) 
derived  from  the  attachments  in  AFSCM  173-4.  Assist  in 
expanding  the  PBS  to  lower  levels  commensurate  with  contract 
management  requirements  of  the  program  office.  This  expanded 
structure  then  serves  as  the  baseline  for  preparation  of  SOW's 
and  the  preliminary  CWBS  to  be  included  in  the  RFP/contract. 

•  Step  5.  Prepare  a  detailed  checklist,  listing  the  items  and 
the  selected  optional  parts  of  the  individual  SOW. 

•  Step  6.  Research  and  prepare  rough  draft  (top  down)  outline 
of  various  tasks,  including  required  attachments  and  expected 
compliance  specifications.  Obtain  samples  of  similar  SOW's, 
annexes,  and  compliance  specifications  and  discuss  with 
persons  familiar  with  these  to  reveal  any  problems  experienced 
with  them. 

•  Step  7.  Require  preliminary  cost  estimates  (in  terms  of  man¬ 
ning  required)  for  each  task  in  coordination  with  the  local  cost 
analysis  activity.  Review  of  these  estimates  permits  early 
trade-off  considerations  on  the  desirability  of  efforts  which 

do  not  address  specified  technical  objectives  or  which  tend 
to  exceed  the  available  budget. 

•  Step  8.  Establish  schedules  for  preparation  of  the  coordinated 
rough  draft  SOW  "fragments".  Coordinate  with  comparable 
schedules  for  preparing  compliance  specifications  and  the 
procurement  schedules. 

3.4  ORGANIZING  AND  PRODUCING  THE  SOW  AND  RELATED 
DOCUMENTS 

Prior  to  producing  the  SOW,  a  security  classification  guide  and  a 
work  breakdown  structure  should  be  developed  for  use  in  classifying  and 
organizing  the  SOW.  Furthermore,  a  Contract  Data  Requirements  List 
must  be  prepared  in  parallel  with  the  SOW.  Because  of  their  importance, 
these  documents  are  discussed  briefly  in  Sections  3.4.1,  3.4.2 
and  3.4.4.  These  documents  are  usually  included  in  the  RFP  as 
attachments.  See  Section  5.4.3. 

3.4.1  Security 

A  DD  Form  254,  Contract  Security  Classification  Specification, 
may  be  developed  for  procurement  actions,  based  on  the  specific  content 
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of  the  SOW  measured  against  the  master  security  classification  guide 
for  the  individual  program.  The  SOW  writer  should  include  in  the  SOW 
any  security  constraints  or  international  aspects  that  will  have  a  signifi¬ 
cant  effect  on  performance  of  the  work  being  called  for. 

3.4.2  Work  Breakdown  Structure  (WBS) 

A  WBS  is  a  product-oriented  tree- structured  representation  of  the 
hardware,  software,  services  and  data  that  comprise  an  acquisition. 

A  WBS  depicts  the  chief  order  in  which  these  tasks  and  products  will  be 
broken  out  for  purposes  of  cost  accounting.  The  single  highest  level 
WBS  Element  represents  the  overall  system  being  developed.  The 
second-level  Elements  represent  major  parts  of  the  system.  MIL-STD- 
881A  establishes  uniformity  within  the  upper  three  levels  of  summary 
Work  Breakdown  Structures  of  defense  materiel  items  for  use  during  the 
acquisition  phase  of  a  program  or  project.  DOD  components  are 
responsible  for  uniformly  expanding  the  summary  structures.  This 
expansion  results  in  the  Program  B reakdown  Structure  (PBS) .  For  this 
expanded  PBS,  a  coding  system  (PBS/C)  was  developed  to  identify  and 
index  each  element  into  its  proper  position  or  level  within  the  summary 
structure.  For  AFSC,  this  is  defined  in  AFSCM  173-4.  This  code  is 
also  used  to  identify  and  index  individual  Contract  Work  Breakdown 
Structure  (CWBS)  elements  as  subdivision  of  the  PBS. 

3.4.2. 1  WBS  Software  Elements 

The  WBS  permits  a  logical  arrangement  of  the  elements  of  the 
SOW,  a  tracing  of  work  effort  expended  under  each  of  these  elements, 
and  easy  identification  of  the  Computer  Program  Configuration  Items 
(CPCI's). 

To  collect  sound  software  cost  data  as  a  basis  for  future  software 
cost  estimates,  software  development  cost  data  should  be  accumulated 
separately  for  each  CPCI  to  be  developed  under  the  contract.  It  is 
desirable  to  identify  the  computational  system  in  the  WBS  at  a  Level  3 
to  assure  adequate  cost  reporting  of  software  data  by  the  contractor. 
MIL-STD-881A  permits  this  for  electronic  systems  but  not  for  aircraft, 
missile  or  space  systems.  Until  this  is  changed,  a  Level  4  or  5  element. 
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as  permitted  by  AFSCM-173-4,  should  be  used,  since  the  computational 
system  and  software  may  be  Contract  Line  Items  (CLI)  and  the  con¬ 
tractor  must  submit  separate  data  for  each  CLI.  (See  Section  5. 4. 2.1, 
below).  For  example.  Guidance  and  Control  Equipment  (Level  3)  may 
have  a  Guidance  Set  (Level  4)  which  may  have  a  Guidance  Computer 
(Level  5),  a  Bulk  Store  Memory  (Level  5),  a  Ground  Control  Computer 
Program  (Level  5),  and  an  In-Flight  Computer  Program  (Level  5). 

Where  comparable  emphasis  is  required  for  software  task  versus  hard¬ 
ware  task,  tailor  MIL-STD-881A  to  reflect  that  emphasis  and  place 
proper  management  attention  on  software  task  during  its  performance 
(e.  g.  ,  tailor  MIL-STD-881A  to  move  a  Level  4  or  5  element  to  Level  3). 

3 . 4 . 2 . 2  Relationship  to  Statement  of  Work 

While  a  Contract  WBS  (CWBS)  must  be  compatible  with  the  Pro¬ 
gram  B  reakdown  Structure,  the  CWBS  may  include  details  which  are 
identified  as  shredouts  of  PBS  elements.  All  tasks  specified  in  the  SOW 
should  be  grouped  according  to  pertinent  PBS  elements  and  priced  con¬ 
tract  line  items.  Levels  of  detail  below  PBS  may  be  outlined  in  SOW 
structuring  to  clarify  interrelationships. 

3.4.2.  3  General  SOW  Preparation  Requirements 

The  practices  stated  below  apply  generally  to  SOW's  for  Validation 
Phase  and  Full-Scale  Engineering  Development  Phase  contracts. 

3. 4. 2. 3.1  SOW  Paragraph  Correspondence  to  Preliminary  CWBS 
Elements .  A  separate  SOW  paragraph  may  be  prepared  corresponding 
to  each  Preliminary  CWBS  Element.  As  a  result,  a  SOW  may  also  have 
a  hierarchical  structure  like  a  WBS.  A  SOW  will  normally  define  tasks 
in  greater  detail  than  the  lowest  level  Preliminary  CWBS  Elements. 

These  subparagraphs  may  be  nested  to  any  depth. 

3 . 4. 2 . 3 . 2  SOW  Paragraph  and  CLI  Correspondence.  At  and  above  some 
level,  the  SOW  paragraphs  may  correspond  to  the  CLI's  (see  Section 
5.4.2. 1  below).  This  correspondence  is  assured  if  the  Preliminary  CWBS 
is  properly  structured  before  the  SOW  is  prepared. 


3 . 4 . 2 . 3 . 3  SOW  Incorporation  of  PBC's.  Each  Validation  Phase  or 
Full-Scale  Development  Phase  SOW  paragraph  should  identify  or  be 


identified  by  the  Program  Breakdown  Codes  (PBC)  of  the  Preliminary 
CWBS  Element  to  which  it  corresponds.  PBC's  may  be  used  in  addition 
to,  or  in  lieu  of,  normal  SOW  paragraph  numbers. 

3.4.3  SOW  Format  and  Composition 

The  program  office  will  select  an  appropriate  SOW  format  from 
the  SAMPLES  provided  in  AFSCP  800-6;  however,  the  selected  format 
should  be  tailored  to  meet  the  specific  program  objectives.  A  typical 
format  is  presented  in  Section  3.2  above. 

3.4. 3.1  General  Guidance 

General  guidelines  are  as  follows: 

1.  Statements  of  Work  should  be  written  in  clear,  concise 
language  which  will  be  easily  understood  by  the  contractor. 

The  importance  of  well  written  SOW's  cannot  be  over¬ 
emphasized  since  they  express  the  requirements  of  the 
Air  Force.  Misunderstanding  can  be  a  significant  factor 
in  contract  negotiation  and  contractor  performance. 

2.  Contractor  tasks  and  technical  requirements  should  be 
included  in  the  Contractor  Tasks  section  of  the  SOW.  The 
major  task  breakdown  should  be  compatible  with  the  effort 
described  in  the  Objective  and  Scope  section  of  the  SOW. 

Task  descriptions  should  clearly  state  what  is  required  of 
the  contractor  and  what  results  are  expected.  When  a 
lengthy  detailed  description  of  a  technical  task/requirement 

is  necessary,  it  may  be  more  feasible  to  prepare  a  compliance 
document , 

3.  Deliverable  reports  and  data  generated  during  contract 
performance  are  listed  in  the  Contract  Data  Requirements 
List  (CDRL/DD  Form  1423,  see  Section  3 . 4.  4.  1 ).  The 
CDRL  is  included  as  a  line  item  in  the  contract  (not  the 
same  line  item  used  for  the  SOW,  see  Sections  5.4.2 

and  5.4.3). 

4.  Clauses  and  provisions  are  included  in  the  Special  and 
General  Provisions  of  the  RFP  (see  Sections  5.  4.  2.  5  and 

5.  4.  2. 7,  below)  and  should  not  be  repeated  in  the  SOW. 

3.4. 3.2  Content 

Contents  of  an  effective  SOW  are  listed  below. 

1.  Table  of  Contents.  Every  Statement  of  Work  that  exceeds 
two  pages  should  have  a  table  of  contents  that  is  readily 
correlatable  with  the  established  preliminary  Contract 
Work  Breakdown  Structure. 


Scope  and  Objectives.  Every  Statement  of  Work  will  include 
introductory  paragraphs  which  should  present  a  clear  des¬ 
cription  and  understanding  of  the  overall  scope  and  objectives. 
Work  outside  the  Scope  may  involve  lengthy  procurement 
lead  time  since  change  orders  may  not  be  used.  Therefore, 
Scope  should  clearly  identify  the  major  elements  of  the  work 
required  and  the  end  result  desired  or  the  product  of  the  effort. 
The  manner  in  which  Scope  is  defined  will  also  govern  the 
amount  of  direction  that  the  government  can  give  and  that  the 
contractor  will  accept  during  the  contract's  life. 

General  Background.  This  SOW  section  should  provide  back  - 
ground  information  such  as  a  brief  history,  the  efforts'  relation¬ 
ship  to  other  procurements,  technology  to  be  used  or  not  used 
(if  appropriate)  and  a  list  of  reference  documents.  Software 
related  references  include:  the  weapon  system  specifica¬ 
tion,  Standard  PBS/PBC  document,  and  Software  Design 
Standards . 

Contractor  Tasks.  This  SOW  section  should  provide  detailed 
descriptions  of  the  studies  and  analyses  to  be  performed,  the 
services  to  be  provided,  the  items  of  equipment  and  software 
to  be  delivered,  and  the  management  systems  to  be  employed; 
it  should  also  provide  reference  to  applicable  compliance 
documents  and  CDRL  sequence  numbers. 

It  is  important  to  note  that  SOW's  are  not  generally 
organized  such  that  software  items  are  conveniently  grouped 
together.  For  example,  in  the  sample  FSED  SOW  organi¬ 
zation  in  Figure  3-1,  Sections  3.2  through  3.8  are  typical 
WBS  Level  2  items.  Each  of  these  probably  contain  hard¬ 
ware  and  software  related  tasks.  The  task  "Design  and 
Development  of  System"  will  be  further  divided  and  sub¬ 
divided  until  (as  mentioned  in  Section  3.4.2.  1  of  this  guide¬ 
book)  the  operational  software  for  the  system  is  addressed 
as  (multiple)  Level  5  task  elements. 

This  section  will  typically  require  development  of  software 
related  items  such  as:  operational  software;  support  soft¬ 
ware  (compiler,  assembler,  linkage  editor,  etc.);  develop¬ 
ment,  test,  and  integration  hardware  facilities  and  related 
software;  computer  program  loader -verifier ;  system  test 
and  integration  software;  and,  occasionally,  CPCI  qualifi¬ 
cation  test  software. 

It  may  also  require  typical  software  related  studies  and 
analysis  (particularly  if  a  validation  or  competitive  prototype 
system  SOW  is  being  prepared)  such  as:  hardware/software/ 
man-machine  and  computer  system  architecture  tradeoffs, 
hard-wired  versus  programmable  digital  processing  tradeoffs, 
computer  memory  allocation,  data  base  design  studies, 
programming  practices,  performance  analysis  of  alternate 
sets  of  equations,  cost  effectiveness  of  HOL  (AFR  300-10) 
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versus  assembly  language,  compiler  effectiveness,  and 
software  design  optimization.  See  also  the  guidebook  on 
Requirements  Analysis  and  Specifications. 

Typical  software  related  compliance  documents  which  are 
refe  r  enced  in  this  section  of  the  SOW  are:  System,  System 
Segment  or  Prime  Item  Development  Specifications,  Program 
technical  requirements  documents,  preliminary  CPCI  Part  I 
Specification,  MIL-STD  480,  MIL-STD  481/2A,  MIL-STD  483 
appendices  II,  VI,  VIII,  XIV,  MIL-STD  1521A. 

See  Section  4.  2  below  for  additional  SOW  tasks. 

5-  Special  Considerations.  This  SOW  section  should  address 
special  instructions  not  directly  related  to  the  contractor 
tasks,  e.g.  ,  management  meetings  and  liaison  with  the 
government  and  associate  contractors. 

3.4. 3. 3  Requirements 

Describe  the  requirements  in  terms  of  performance  in  complete 
detail,  whether  by  direct  statements  or  reference  to  other  documents, 
such  as  specifications  and  standards.  Normally,  specifications  and 
standards  are  compliance  documents  and  are  therefore  binding  require¬ 
ments.  Do  not  cite  a  compliance  document  in  its  entirety  unless  all  of 
the  provisions  are  required.  Tailoring  to  minim  im  needs  is  mandatory. 
Identify  specific  exceptions  or  the  specific  applicable  requirements  of  a 
compliance  document  in  the  appropriate  SOW  task  on  Compliance  Documents. 
The  requirements  of  a  compliance  document  may  be  expanded  by  including 
appropriate  description  in  an  annex  to  the  SOW.  Guidelines  for  using 
and  tailoring  a  compliance  document  are  presented  with  examples  in  the 
RSS  Guidebook.  Section  5.4.  1  and  in  SAMSOP  800-6.  AFR  800-25  pro¬ 
vides  additional  guidance  and  information.  Each  tailored  compliance 
document  may  be  assigned  its  own  SOW  paragraph  number  for  referencing 
by  SOW  tasks.  The  SOW  must  indicate  the  applicability  of  each  com¬ 
pliance  document,  either  in  the  tailored  application  or  the  SOW  task  that 
requires  the  document.  Specific  and  appropriate  references  to  the 
specifications,  military  specifications,  and  military  standards  are 
essential  to  clear,  precise,  and  appropriate  SOW  task  descriptions  and 
Data  Item  Definitions. 


Do  not  cite  Regulation  documents  for  compliance  except  where  the 
contractor  is  required  to  accomplish  tasks  normally  performed  by  the 
government  -  such  as  operation  and  maintenance  contracts.  Do  not  cite 
other  government  documents  such  as  manuals,  handbooks,  pamphlets, 
etc.  ,  for  compliance. 

3. 4. 3. 4  Procedures 

When  immediate  decisions  cannot  be  made,  it  is  usually  possible 
to  include  a  procedure  for  making  them.  It  can  be  merely  a  statement 
such  as  "as  approved  by  the  contracting  officer  '  or  "at  the  contractor's 
discretion"  or  "the  contractor  submits  this  report  each  time  a  Category  B 
failure  occurs.  " 

3.4.3. 5  Language 

The  writer  should  be  aware  that  SOW's  often  have  to  be  read  and 
interpreted  by  persons  of  varied  backgrounds.  Therefore,  the  SOW  should 
be  worded  to  make  more  than  one  interpretation  virtually  impossible. 
Careful  and  exact  descriptions  will  avoid  misunderstandings  during  the 
life  of  the  contract.  Some  things  to  bear  in  mind  when  writing  are 
included  below: 

1.  Use  active  rather  than  passive  voice.  Say  "The  contractor 
shall  conduct  a  test"  rather  than  "A  test  shall  be  conducted.  ". 

2.  Do  not  use  open  ended  phrases  such  as  "but  not  limited  to.  .  .  " 

3.  Use  "shall"  to  stipulate  mandatory  provisions.  Use  "should" 
to  designate  a  preferred  item  or  practice  and  "may"  to 
designate  an  acceptable  item  or  practice.  Use  "will"  to 
designate  a  declaration  of  intent  on  the  part  of  the  Government. 
"Will"  may  also  be  used  when  it  is  necessary  to  designate 
simple  futurity,  for  example,  "Power  for  the  equipment  will 
be  provided  by  the  existing  ground  stations.  " 

4.  The  contract  imposes  rights  and  obligations  on  both  parties. 

If  it  doesn't  say  "it"  in  the  contract,  "it"  is  out  of  scope. 

That  means  if  you  want  "it"  done,  you  will  need  a  contract 
modification  that  may  change  cost,  schedule  or  performance. 

5.  Limit  abbreviations  to  those  in  common  usage.  In  any  case, 
the  first  time  an  abbreviation  is  used,  give  the  item's  title 
and  follow  that  with  the  abbreviation  in  parentheses. 
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3.4. 3. 6  Specific  Purpose 

Keep  the  specific  purpose  in  mind  and  eliminate  meaningless  jargon 
from  SOW's.  State  what  results  are  required,  not  how  the  contractor  is 
to  do  the  job  nor  what  you  think  he  will  need.  Describe  fully  what  is 
required  to  satisfy  the  contract.  The  following  questions  can  be  used  to 
judge  whether  material  should  be  in  an  SOW: 

1.  Is  it  necessary  in  order  to  accomplish  the  effort? 

2.  Does  it  tell  the  contractor  what  he  is  required  to  do? 

3.  Is  it  necessary  in  order  for  the  contractor  to  determine 
what  is  required  of  him? 

4.  Is  there  a  method  to  determine  when  the  basic  task  is 
complete  (i.  e.  ,  is  it  priceable)  ? 

Material  or  tasks  that  do  not  pass  these  tests  should  generally  be 
redefined  or  left  out  of  the  SOW. 

3.4.4  Data  Management 

3.4.4. 1  Relationship  of  RFP/SOW  to  CDRL 

The  Contract  Data  Requirements  List  (CDRL)  is  a  list  of  data 
requirements  that  is  authorized  for  a  specific  procurement.  This  list 
is  prepared  on  the  DD  Form  1423,  "Contract  Data  Requirements  List,  " 
or  its  mechanized  equivalent  (AFSC  Forms  707,  708,  709).  The  CDRL 
is  established  as  an  alternative  to  setting  forth  an  extensive  listing  of 
line  or  subline  items  in  Section  E  of  the  Contract  Schedule.  The  CDRL 
or  its  mechanized  equivalent  is  included  in  the  RFP  as  either  an  exhibit 
or  an  attachment  to  the  contract. 

As  used  here,  the  term  "data"  includes  all  administrative,  manage¬ 
ment,  financial,  scientific,  engineering,  and  logistic  information  and 
documentation  which  are  acquired  for  delivery  or  deferred  delivery 
(AFSCR  310-2)  from  Air  Force  contractors. 

Preparation  of  the  CDRL  should  be  a  coordinated  effort  between 
the  SOW  Project  Officer  and  the  Program  Office's  Data  Management 
Officer  (DMO).  Planning  for  data  requirements  should  be  considered 
in  the  early  phases  of  the  SOW  effort.  Do  not  include  data  preparation 
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instructions  in  the  SOW  tasks.  When  ihe  effort  described  in  a  SOW  task 
results  in  the  generation  of  data,  the  task  should  not  directly  address 
the  preparation  or  delivery  of  the  data.  It  may  however,  reference  the 
data  resulting  from  the  effort  to  the  appropriate  CDRL  sequence  item 
number,  that  is,  "CDRL  XXXX,  "  preferably  at  the  end  of  the  task.  The 
CDRL  (DD  Form  1423)  must  reference  the  SOW  paragraph  number  or 
PBC.  Both  the  SOW  and  the  CDRL  must  identify  the  Data  Item  by  the 
same  name.  Cut  costs  by  using  one  CDRL  entry  rather  than  several, 
when  pos sible,  e.  g.  ,  study  reports. 

3.4.4. 2  CDRL  Entry 

Each  Data  Item  (i.e.  ,  each  document  and  each  computer  storage 
media  containing  a  software  Cl)  to  be  delivered  under  the  planned  con¬ 
tract  must  be  identified  in  a  CDRL  entry.  For  CPCI  technical  data,  the 
CDRL  must  define  the  Data  Item  (by  DID  reference)  and  the  terms  and 
frequency  of  delivery.  The  software  media  related  CDRL  (i.e.,  DI-E-30145 
or  A30008/M)  must  not  specify  delivery  requirements.  Instead  it  must 
reference  the  Delivery  Schedule.  Since  the  software  media  is  an  end  item, 
delivery  of  each  item  is  called  for  in  a  Contract  Line  Item.  The  media 
CDRL  should  be  separated  from  the  technical  data  CDRL.  A  method  for 
doing  this  is  shown  in  Figure  1-1. 

Each  CDRL  entry  also  includes  blank  fields  for  contractor  estimates 
of  Data  Item  size  and  price.  For  CDRL  entries  relating  to  technical  data 
associated  with  software  the  contractor's  proposal  must  provide  this 
information.  (Usually,  RFP  Section  C  states  that  a  proposal  that  lacks 
these  price  estimates  may  be  rejected  as  non-responsive).  Cost/price 
data  related  to  the  media  CDRL  is  inappropriate,  since  these  prices  are 
priced  against  the  Contract  Line  Item  calling  for  the  software  development. 

3.4.4.  3  Completion  Dates  and  Periods  of  Performance 

Each  SOW  paragraph  that  defines  a  task  must  have  an  appropriate 
completion  date  or  Period  of  Performance  for  that  task.  The  SOW  must 
not  specify  delivery  dates  for  Data  Items;  these  mist  be  C  DR  L -defined . 

A  task  completion  date  or  Period  of  Performance  may  be  included 
explicitly  in  the  SOW  paragraph  that  prescribes  the  corresponding  task. 
However,  it  is  normally  preferable  to  include  task  completion  dates  and 


-21  - 


Periods  of  Performance  in  the  Delivery  Schedule  (RFP/contract  Section  H, 
see  Section  5.  4.  2. 3,  below)  and  to  refer  to  the  Delivery  Schedule  in 
the  SOW  paragraphs.  The  recommended  approach  concentrates  all  date- 
related  SOW  requirements,  which  simplifies  their  updating  and  cross¬ 
checking  for  feasibility. 

3. 4. 4. 4  Policies  and  Procedures 

AFSCR  310-1  provides  policies  and  procedures  for: 

•  Preparing  DD  Form  1423,  Contract  Data  Requirements  List, 
which  becomes  a  contract  attachment  or  exhibit,  and  governs 
the  delivery  of  all  data,  other  than  ASPR  requirements  in  the 
general  or  special  contract  provisions. 

•  Using  DOD  standard  DD  Form  1664,  Data  Item  Desc r iptions , 
which  are  contractually  incorporated  by  reference  on  DD 
Form  1423.  Already  approved  DID's  listed  in  DOD  5000.  19-L, 
Vol  II  should  be  used  whenever  possible, 

•  Developing,  approving,  and  using  program  peculiar,  or  unique, 
data  requirements  as  well  as  modifications  to  capitalize  upon 
contractor  internal  data  in  relaxed  format. 

3.4.4. 5  Software  DID' s 

Major  documents  for  monitoring  contractor  performance  are  usually 
contractor  prepared  and  are  used  for  configuration  management,  engineer¬ 
ing,  test  system  operation,  and  support.  These  documents  are  associated 
with  the  computer  program  life  cycle  as  presented  in  the  Documentation 
Guidebook  in  this  series. 

The  DOD  authorized  data  list  identifies  standard  data  item  des¬ 
criptions  (DID's)  for  use  in  acquiring  data  from  contractors.  Examples 
of  DID's  applicable  to  computer  resource  data  requirements  are  shown 
m  Table  3-1.  Care  should  be  taken  to  tailor  the  DID's  to  actual 
requirements . 

Wherever  a  modified  DID  prescribes  a  CDRL  entry' s  form  and 
content,  the  DID  identification  must  indicate  this  (e.g.,  by  appending 
"/M"  to  the  DI  number).  The  modifications  themselves  must  be  stated 
in  the  CDRL  entry  itself,  or  on  backup  sheets  attached  to  the  CDRL 
entries,  or  on  the  modified  DID  form  (DD  Form  1664)  which  may  be 
included  as  an  annex  to  the  CDRL.  Besides  the  CDRL  entries  and  backup 
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Table  3-1.  AF  DID's  Applicable  to  Software  Acquisition 


DID 

Identifier 

Data  Item  Name 

Outdanc  ** 

C iimt  *nts 

[  ADMINISTRATIVE  'MA.N'ACh.MKN  I 

•  f 

C  RISP 

H00  14  V.,1  II 

Prepared  by  CR’.VC  <(  n.p  ;t«  r 
Resources  Working  Group) 

A  -  3002 

R&D  Status  Report 

A-  3007 

Program  Schedule 

| 

A-3009 

I ’roe rant  Milestones 

A -302  2 

Contract  Data  Management  Plan 

A-  3027* 

Data  Accession  List 

(  ontractor  internal  data 

1  A  -  3  02  9  * 

| 

Agenda  -  Design  Reviews,  Configuration 
Audits,  Demonstrations 

1531  A 

SRR ,  SDR,  PDR,  C  DR,  FCA.  PC  A 

|  A- 30008 /M 

Computer  Programs;  Data  and  Printouts 

[  ENGINEERING  AND  CONKIGC  RATION  MANAGEMENT 

E-  ill))  * 

System  (Segment)  Specification 

48  3,  App.  3 

’2 

E-M04 

Addendum  Specification 

483,  App.  4 

To  Pa  rt  I  or  Pa  rt  II 

E-  3107 

Installation  Completion  Notification 

483,  App.  15 

Change  implementation 

E-3108 

Configu  ration  Management  Plan 

483,  App.  1 

E-  31 14 

System  Mod.  Design  Data  and  Reports 

Basis  for  modifications 

E  -  3  1 1 6 

System  Allocation  Document 

48  3,  App.  1  1 

E-  3117 

Segment  Specification  (Modification 
program) 

483,  App.  3 

E-3118* 

Minutes  of  Reviews  and  Audits 

1  52 1  A 

SRR.  SDR,  PDR.  CDR,  FCA,  PCA 

E-3119A* 

Computer  Program  Development 
Specification 

483,  App.  6 

Part  I 

E-3120A* 

Computer  Pr  >gram  Product  Specification 

483,  App.  6 

Part  II  (includes  flow  charts) 

E-3121 

Version  Description  Document 

483.  App.  8 

Version  release 

E-3122  ♦ 

Conf iteration  Index  (Computer  program) 

48  3,  App.  8 

Approved  changes 

E-3123 

Change  Status  Report  (Computer  program) 

483,  App.  8 

Proposed  changes. 

E-  3 127 

Advance  Chance/Study  Notice 

480 

E-3128* 

Engineering  Change  Proposal  (PCP) 

483,  App.  14 

(Related  to  SCN) 

F.-3129 

Request  for  Deviation/Waiver 

480 

E -  3 1 34  * 

Specification  Chance  Notice  (SCN) 

(Computer  Programs) 

483,  App.  8 

(Related  to  ECP) 

E-  3 145 

Engineering  Drawing  for  Reviews,  etc. 
(Interface  Control  Drawings) 

483,  App.  2 

E-3126A 

Request  for  Nomenclatur e 

E-  30145 

Computer  Software /Computer  Program/ 
Computi  r  Data  Rase  Configuration  Item(  s) 

483,  App.  6 

Preparation  Requirements 

HUMAN  FACTORS 

H -  3251 

Personnel  Sub sy stem /Human  Factors  Plan 

j 

H-  3258A 

Training  Support  Data 

In  place  of  manuals 

H-3261A 

Human  Engineering  Design  Approach 

H-  3267 

Evaluation  Needs/Exercise  Requirements 

Input  to  software  requirements 

H- 7012 

Operator/C ritical  Tasks  Analysis 

Requirements  and  Documentation 

H-3269A 

Training  Needs/Exercise  Requirements 

Input  to  software  requirements 

H-3272 

Personnel  Subsystem  Test  and 

Evaluation  Plan 

* 

Pa  rt  of  minimum  software  documentation  s ot . 
This  data  item  is  not  contractor-developed. 
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Table  1-1.  AF  DID's  Applicable  to  Software 
Acquisition  (Concluded) 


|  :>»> 

|  Identiti*  r 

Data  Item  Name 

Guidant  e 

[  TECFINICAl  FT  Bt.ICATIONS 

M-  34<M 

T.O.  Publication  Plan 

1  r  p  jsing  user  dot  . r  1 .  ut  .ti 

M-  *402 

Status  and  Schedules 

Documentation  status 

M  -  1409* 

1  ositional  Handbook 

M  -  34tOf 

si  r  s  Manual 

For  all  programs  deliver*  <! 

M-  1411 

Computer  Programming  Manual 

\1-  141- 

Catalog.  Glossary  of  Computer  Pmiiranis 
and  Documentation 

M-  1407  A 

1  et  hnic  a  1  Order 

RE FATED 

DESIGN  DOCUMENTS 

R-3^27 

Systems  Security  Plan 

Development  and  operation 

R-3^28 

Clandestine  Vulnerability  Analysis 

R  equirements 

I*  -  3  529 

■system  Security  Standard 

1  ">pe  rational 

R-353S 

Reliability  '  Maintainability  Allocat  i  >ns 
Assessment,  Analysis 

R-3537A 

Reliability  Maintainability  Data 

Reporting  and  Feedback  Failure  Reports 

1  SYSTEMS/ SI’ F3  S  Y  S  T  E  M  ANALYSES 

S-3S81 

Subsystem  Design  Analysis  Report 

(See  also  S-3<  19) 

S-3582 

Subsystem  Engineering  Development  Record 

(See  also  S-  3*  19) 

S-  1591 A 

Technical  Reports 

Requires  DDC  and  Air  niv. 

Library  distribution 

S-3604 

Functional  Flow  Diagrams 

4  99  A 

Requirements  derivation 

S-360- 

Requirements  Allocation  Sheets 

4  99  A 

Requirements  derivation 

S-3606 

System /Design  Trade  Studies 

499A 

Requirements  dc  rivati  n 

S-3607 

Schematic  Block  Diagrams 

49QA 

Requirements  derivati  n 

S-  3608 

Time  Line  Sheets 

499  A 

Requirements  derivation 

S-3618 

System  Engineering  Management 

Plan  1SF.MP) 

499  A 

Overall  management 

S-  361 9 

Technical  Performance  Measurement 

Rrp.irt 

4  99  A 

Per  SEMP 

S-J0567A 

Computer  Pr  'gram  Dev.  Plan  (CPDP) 

MOO-14  Vo.  II 

Roc  >mmendcd  f*>r  Sou  ret  Select  1  >•  ! 

|  S-30S59 

I  •  t  hnie.il  (Operating  Report 

N  •  DI)f  distri  -.’ion  required 

1  TEST _ i 

l 

lest  and  Evaluation  Master  Plant  TEMP) 

AFR  80-14 

A I  SC  Supplement  I 

1  3701 

System  Test  Plan 

Alternative  to  3703  /370* 

r-?70i* 

Category  I  lest  Plan 'Pr -cedures 

CPC I,  subsystem 

T -  3706  * 

Category  11  Test  Plan/Prot  edures 

System  level 

T-17I7* 

Category  I  Test  Report 

CPCI,  subsystem 

T  -  3  7 1 8 

T  st  Reports  -  General 

Quick  Look,  Interim,  Addendum 

T  -  3  7 1 9  * 

Category  II  Test  Report 

System  level 

T -  3729 

Test  Facility  Requirements  Document 

Prior  to  system  testing 

■  ftwar<  . . 

*  This  data  it*  m  is  n  -t  c>ntr.ictor-dev«  1  ped. 
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sheets,  the  CDRL  should  define  abbreviations  used  on  the  CDRL  entry 
forms,  provide  instructions  for  interpreting  or  completing  CDRL  entries, 
a iid  provide  mailing  addresses  for  the  distribution  lists. 

CDRL  preparation  and  DID  modification  are  further  described  in 
AFSCR  310-1,  Management  of  Contractor  Data.  This  regulation  requires 
justifying  the  need  for  each  CDRL-defined  document,  to  minimize  project 
cost. 

3. 4. 4. 6  Enforcement  of  Proposed  Plans 

A  SOW  provision  is  necessary  to  require  contractors  to  comply 
with  plans  they  generate,  such  as  the  Computer  Program  Development 
Plan  (CPDP).  The  CDRL  should  also  call  for  updating  each  such  plan. 

If  delivery  of  a  plan  is  required  as  part  of  the  contractor's  proposal,  the 
RFP  Section  C-2  must  specify  it.  Some  words  of  caution  are  needed. 
Regardless  of  who  originated  the  document,  if  a  plan  is  incorporated  in 
the  contract  as  a  compliance  document,  the  plan  will  normally  be  construed 
as  a  government  requirement  on  the  contractor.  Therefore,  every  word 
must  convey  the  intent  of  program  office  personnel,  since  subsequent 
changes  may  impact  contract  cost,  schedule  or  performance.  (See  also 
Section  5.4.  1.3.2,  below). 

3.4.4. 7  Data  Checklist 

A  minimum  set  of  recommended  data  are  indicated  by  asterisks  in 
Table  3-1.  In  general,  the  RFP/SOW  writing  team  should  be  guided  by 
the  following  considerations  in  determining  data  requirements: 

1.  Does  the  intended  use  of  data  delivered  under  contract  meet 
one  or  more  of  the  following  purposes: 

•  Provide  the  basis  for  required  decisions. 

•  Document  technology  for  future  use. 

•  Provide  for  reprocurement  or  manufacture. 

•  For  instructional  purposes. 

•  For  logistics  support  (maintenance,  installation,  etc.). 

•  Record  test  results. 

•  Assess  reliability  and  supportability. 

•  Report  current  status  in  a  timely  manner. 

•  Operations. 
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2.  Was  a  data  call  issued?  How  were  the  scope  and  magnitude 
of  this  data  call  determined? 

3.  Does  the  RFP  instruct  the  contractor  to  price  each  data  item? 

4.  Are  all  data  items  selected  to  be  listed  on  DD  Form  1423 
in  response  to  the  data  call  completely  justified  to  the  DMO 
by  the  originator? 

5.  Are  there  duplicate  or  overlapping  requirements? 

6.  Are  distribution  lists  held  to  a  minimum  number  of 
recipients  having  a  positively  established  requirement 
for  the  daia  item? 

7.  Is  the  DD  Form  1423  in  the  RFP  file  current? 

8.  Will  the  contractor  format  suffice? 

9.  Have  all  MIL-Specs,  Standards,  and  DID's  been  reviewed 
for  possible  deletion  or  tailoring  in  order  to  save  costs? 

3.4,5  Statement  of  Work  Checklist 

The  following  checklist  for  SOW's  provides  some  of  the  considera¬ 
tions  which  the  writers  must  bear  in  mind. 

1.  Is  the  SOW  sufficiently  specific  to  permit  the  writer  and  the 
contractor  to  make  a  list  of  manpower  and  resources  needed 
to  accomplish  it? 

2.  Are  specific  duties  of  the  contractor  stated  in  such  a  way  that 
he  knows  what  is  required  and  that  the  contract  administra¬ 
tion  office  representative  who  signs  the  acceptance  report 
can  tell  whether  the  contractor  complied? 

3.  Are  sentences  written  so  that  there  is  no  question  of  whether 
the  contractor  is  to  be  obligated  (that  is,  "the  contractor  does 
this  work,  "  not  "this  work  will  be  required"). 

4  Is  the  proper  compliance  document  shown?  Is  it  really  per¬ 
tinent  to  the  task?  Is  it  properly  tailored? 

5.  Are  any  military  specifications  or  exhibits  applicable? 

In  whole  or  in  part?  If  so,  are  they  properly  tailored? 

(Use  the  latest  available  revisions  or  issue  of  each  document). 

6.  Is  general  information  separated  from  direction  so  that 
background  information,  suggested  procedures,  and  the  like, 
are  clearly  distinguishable  from  contractor  responsibilities? 
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7.  Does  the  schedule  reflect  a  date  for  each  thing  the  contractor 
is  to  do  or  deliver?  If  elapsed  time  is  used,  does  it  specify 
calendar  days  or  work  days? 

8.  Are  proper  quantities  shown? 

9.  Have  the  headings  been  checked  for  format  and  grammatical 
usage?  Are  subheadings  comparable?  Is  the  text  compatible 
with  the  title?  Is  a  miltidecimal  numbering  system  used  or 

a  W  BS-consistent  system  used? 

10.  Have  extraneous  material  and  crossreferences  to  contract 
clauses  and  general  provisions  been  expunged? 

11.  Does  SOW  task  reference  CDRL  Data  Item(s)  generated  by 
the  task' 

12.  Have  all  extraneous  data  requirements  been  eliminated  and 
all  tailoring  accomplished  '1 

3.4.6  RFP/SOW  Reviews 

Figure  3-2  depicts  in  block  form  the  various  steps  involved  in 
showing  the  sequence  of  events  in  SOW  development  as  they  relate  to 
responsible  or  interested  activities.  During  the  development  of  the  speci¬ 
men  SOW,  the  project  officei  should  ensure  adequacy  of  content  through 
integrated  efforts  of  the  members  of  the  SOW  writing  team.  Project 
officers  should  ensure  that  all  elements  of  the  program  office,  staff 
functional  specialists,  user  agency  and  other  agencies  review  the  SOW 
to  determine  that  technical  and  data  requirements  being  procured  fulfill 
a  common  system  objective. 

After  all  comments  are  incorporated,  the  SOW  writing  team  then 
reviews  the  final  document.  After  compilation  of  the  draft,  a  coordina¬ 
tion  cycle  is  usually  necessary  to  ensure  that  it  is  complete  and  com¬ 
prehensive.  Coordinators  are  those  persons  who  have  a  functional  or 
command  responsibility.  Coordinators  should  not  give  general  impres¬ 
sions,  but  should  concur  or  suggest  specific  changes  in  the  language  useo. 
When  the  coordination  cycle  is  completed  and  the  specific  changes  have 
been  coordinated  and  agreed  upon,  a  final  draft  should  be  prepared.  The 
final  draft  should  then  be  given  a  final  review  by  the  program  manager 
to  ensure  that  it  accurately  reflects  program  requirements. 

Additional  review's  and  some  of  the  above  reviews  are  done  in 
conjunction  with  the  RFP  reviews  discussed  in  Section  5.3. 
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4.  SOW  PHASE  AND  DISCIPLINE  SPECIFIC  GUIDELINES 


4.1  ACQUISITION  LIFE  CYCLE 

The  discussion  on  the  various  life  cyc'e  phases  is  based  on  AFSCP 
800-3.  The  system  life  cycle  consists  of  p  ases  through  which  a  weapon 
or  support  system  must  go  if  it  is  to  be  delivered  to  the  operational 
inventory  as  shown  in  Figure  4-1.  Figure  4-2  shows  typical  SOW  effort 
in  the  phases. 

Computer  program  development  can  be  conceptualized  as  the 
computer  program  life  cycle  shown  in  Figure  4-1.  This  cycle  may  span 
more  than  one  system  acquisition  life  cycle  phase,  or  occur  in  any  one 
phase.  For  example,  a  mission  simulation  computer  program  may 
undergo  all  of  the  phases  of  the  computer  program  life  cycle  during  the 
conceptual  phase,  while  a  mission  application  program  may  undergo 
these  phases  during  the  validation,  full-scale  development,  and  production 
phases.  The  computer  program  life  cycle,  and  the  formal  activities 
associated  with  it  (configuration  management,  technical  reviews,  testing 
and  audits,  and  so  forth),  will  occur  at  least  once  for  each  CPCI  during 
the  system  acquisition  life  cycle.  The  activities  need  not  be  sequential, 
instead,  there  are  potential  loops  between  all  the  phases.  For  example, 
design  may  reveal  problems  in  performance  and  cost  which  lead  to  the 
revision  of  requirements  and  reinstitution  of  certain  analyses.  Checkout 
may  reveal  errors  in  design,  which  in  turn  may  lead  to  redesign  or 
requirements  revision.  The  phases  of  the  computer  program  life  cycle 
are  discussed  in  the  Contracting  for  Software  Acquisition  Guidebook  in 
this  series. 

4.2  TYPES  OF  SOW  TASKS 

The  matrix  provided  in  Figure  4-3  (Ref.  SAMSOP  800-6)  depicts  the 
various  management/technical  disciplines  and  their  applicability  to  a 
SOW  for  specific  phases  of  the  system  life  cycle.  The  matrix  is  indicative 
of  the  appropriate  tasks  to  be  considered  for  a  specific  type  of  procure¬ 
ment.  It  includes  the  various  program  phases  defined  in  AFSCP  800-3 
and  a  breakdown  of  the  various  types  of  efforts  for  which  program  offices 
prepare  contract  SOW's.  (The  Software  Development  column  is  in  the 
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Figure  4-2.  Government- Contractor  Statement  of  Work  Effort  in  the  System  Life  Cycle 
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Full-Scale  Engineering  Development  Phase  columns).  This  should  not  be 
construed  to  mean  that  there  are  no  software  tasks  during  the  other  phases). 

Sources  of  SOW  material  are  Product  Division  Statement  of  Work 
preparation  pamphlets,  e.  g.  ,  SAMSOP  800-6,  which  contains  33  short 
appendices  on  different  potential  SOW  tasks,  e.  g.  ,  Computer  Resources 
Management,  Configuration  Management,  Quality  Assurance,  Test  and 
Evaluation,  etc.  Each  appendix  includes  basic  instructional  information 
for  the  SOW  writer  in  a  standardized  format.  Previous  or  similar  con¬ 
tracts  are  an  excellent  source  of  task  statements.  The  other  guidebooks 
in  this  series  should  also  be  consulted  for  definition  of  specific  tasks, 
e.g.,  CM,  QA,  VV&C,  etc.  However,  these  tasks  should  be  tailored  to 
specific  program  objectives,  insuring  that  the  task  effort  includes 
essential  requirements  only. 

4.3  VARIABLES  AFFECTING  SOW  CONTENT 

There  are  many  variables  which  affect  the  content  of  the  SOW  as 
discussed  below. 

4.3.1  Complex  Weapon  Systems 

For  a  large  complex  weapon  system,  all  SOW's  may  be  made  fairly 
consistent  by  the  use  of  standardized  paragraph  titles  and  numbers,  each 
with  a  corresponding  preliminary  CWBS  element.  For  the  standardized 
paragraphs  which  do  not  apply  to  the  specific  SOW,  the  paragraph  number 
may  be  included  with  a  NOT  APPLICABLE  for  the  paragraph  title.  An 
SOW  paragraph  on  Compliance  Documents,  e.g.,  SOW  paragraph  3.1, 
may  be  treated  in  much  the  same  way,  i.  e. ,  standardized  sub-paragraph 
numbers  for  particular  documents,  with  NOT  APPLICABLE  in  place  of 
the  document  reference  when  appropriate.  This  standardization  is  used 
to  improve  preparation  of  the  numerous  SOW's  for  the  system  and 

) 

coordination  of  them  among  the  many  functional  disciplines,  especially 
those  with  common  requirements/tasks  in  several  SOW's. 

4.3.2  NSCC  A/PATE 

Nuclear  Safety  Crosscheck  Analysis  (NSCCA)  and  Performance 
Analysis  and  Technical  Evaluation  (PATE)  are  performed  by  a  contractor/ 
agency  other  than  the  development  contractor.  PATE  is  one  form  of 


Independent  V eriflcation  and  Validation  (IV&V).  NSCCA  is  accomplished 
to  implement  the  requirements  of  AF R  122-9  and  AFR  122-10.  PATE  is 
accomplished  primarily  to  independently  determine  that  the  software  met 
its  requirements.  The  developer's  contract  should  include  delivery  of 
the  software  and  sufficient  CDRL  items  to  the  NSCCA/PATE  cont ractor ( s ) 
or  to  other  V&V  contractors  to  enable  them  to  perform  the  required 
analyses.  See  WhC  Guidebook  for  specific  CDRL  recommendations. 

4.3.3  Systems  Engineering  Contractors 

A  systems  engineering  contractor  who  supports  the  Air  Force 
requires  delivery  of  the  software  and  most  of  the  technical  CDRL  items. 
Therefore,  the  deliveries  should  be  reflected  in  RFP/Contract  Section  H 
and  the  CDRL.  SOW  paragraph  4.0  (Special  Considerations)  and  an  RFP/ 
Contract  Special  Provision  should  specify  the  interrelationship  of  the 
contractor  with  the  systems  engineering  contractor  as  well  as  the  customer 
and  associate  contractors. 

4.3.4  Support  Software 

All  software  used  to  support  design,  development,  and  test  of  the 
operational  software  should  be  identified  and  placed  under  configuration 
control .  Rights  to  thi s  software  are  discus sed  further  in  Section  5.4.2.  5 .  3 
below.  The  need  for  its  acquisition  is  pointed  out  there.  Delivery  of  that 
software  and  its  associated  documentation  required  by  the  using  and  main¬ 
taining  agencies  should  be  established  in  the  contract. 
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5.  GUIDELINES  FOR  RFP  PREPARATION 


A  Request  for  Proposal  (RFP)  is  a  formal  document  used  by  the 
Air  Force  to  solicit  proposals  from  potential  contractors  for  required 
supplies  and  services.  The  RFP  must  provide  an  accurate  description 
of  what  is  being  bought,  what  the  conditions  are  for  its  acquisition,  what 
is  desired  in  proposals,  and  what  the  evaluation  factors  are  for  com¬ 
petitive  awards.  Each  section  of  the  RFP  and  all  of  its  attachments  and 
exhibits  impose  requirements  on  offerors.  All  these  requirements 
(except  those  in  Part  I  of  the  RFP)  are  included  in  the  contract.  The  time 
and  effort  invested  in  producing  quality  RFP's  results  in  proposals  which 
are  more  responsive  and  easier  to  evaluate.  This  all  helps  to  assure  a 
good  contract.  (Section  3  of  this  guidebook  discusses  the  SOW  and  related 
attachments . ) 

5.1  RESPONSIBILITIES 

5.1.1  General  Responsibilities 

The  Procuring  Contracting  Officer  (PCO)  generally  is  responsible 
for  preparing  and  issuing  an  RFP  with  concurrence  of  the  program 
manager.  Technical,  financial,  logistics,  and  management  experts  must 
actively  participate  with  the  PCO  in  preparing  and  reviewing  the  RFP. 
Final  review  and  editing  are  accomplished  to  ensure  continuity  and  con¬ 
sistency  and  avoid  duplication,  which  are  frequent  complaints  by  bidders. 
Participants  preparing  the  RFP  should  be  familiar  with  the  program 
guidance  in  the  various  program  background  documents. 

5.1.2  Specific  Responsibilities 

Directorate  of  Procurement  has  the  basic  responsibility  for 
preparation  of  the  formal  contract  solicitation. 

Program/Project  Directors  prepare  and  identify  SOW's,  CDRL, 
specifications  and  other  compliance  documents  according  to  AFR,  AFSCR. 
local  regulations  and  procurement  directives  and  program  office  direction 
(e.g.,  MENS,  PMD,  PMP,  DCP,  etc.). 

Procuring  Contracting  Officers  (PCO's)  with  procurement  staff 
support  prepare  their  respective  solicitations  and  contractual  documents 
in  compliance  with  ASPR,  ASPR  supplements,  and  local  directives. 
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RI  P  ORGANIZATION 

AFR  70-15,  which  explains  the  Major  Defense  System  Source 
Selection  process  for  both  Validation  Phase  and  FSED  Phase  competitive 
contracts,  should  be  reviewed  before  RFP  preparation.  The  policies  and 
procedures  of  AFR  70-15  may  also  be  tailored  for  use  in  Less -Than-Major 
System  acquisition  programs,  or  AFSCR  80-15  R&D  Source  Selection 
Policy  and  Guidance,  may  be  applied. 

RFP  organization  objectives  are  to  maintain  the  intent  and  content 
of  the  Uniform  Contract  Format  (UCF)(ASPR  3-501)  and  to  communicate 
clearly  and  concisely  with  potential  offerors.  These  objectives  can  be 
accomplished  by  using  all  Parts  and  Sections  of  the  UCF  as  the  same 
Parts  and  Sections  of  the  RFP  as  shown  in  Figure  5-1. 

The  UCF  and  RFP  are  separated  into  four  parts  that  group  similar 
documents  together.  There  is  no  requirement  for  grouping  the  Parts 
of  the  RFP  into  specific  volumes. 

5.2.1  RFP  Proposal  Preparation  Instructions 

RI  P  Part  I  General  Instructions  contains  Instructions  for  Proposal 
Preparation  (IFPP)  including  such  information  as  the  name  and  identifi¬ 
cation  number  assigned  to  the  potential  contract,  the  issuing  office,  and 
the  Government  official  point  of  contact  for  the  proposal.  It  identifies 
all  parts  of  the  RFP,  specifies  terms  for  delivery  of  the  proposal,  and 
contains  questions  to  be  responded  to  by  each  offeror  (bidder).  It  pro¬ 
vides  guidance  as  to  the  type  of  proposal  expected,  information  to  be 
included,  format  of  the  proposal,  mechanics  of  submission,  basis  for 
contract  award,  grounds  for  rejection,  security,  proposal  size  limita¬ 
tions,  number  of  copies  required,  and  the  type  of  contract  planned.  It 
also  provides  the  general  criteria  to  be  used  by  the  Government  to 
evaluate  proposals  (including  relative  importance  of  technical  merit, 
p  rice,  etc  .  ) . 


UCF  AND  RFP  PART  I  -  GENERAL  INSTRUCTIONS 


SECTION  A  -  COVER  SHEET 

SECTION  B  -  CONTRACT  FORMS  AND  REPRESENTATIONS,  CERTI¬ 
FICATIONS,  AND  OTHER  STATEMENTS  OF  OFFEROR 
OR  QUOTER 

SECTION  C  -  SOLICITATION  INSTRUCTIONS,  CONDITIONS,  AND 
NOTICE  TO  OFFERORS 

SECTION  D  -  EVALUATION  FACTORS  FOR  AWARD 

UCF  AND  RFP  PART  II  -  THE  SCHEDULE 

SECTION  E  -  SUPPLIES/SERVICES  AND  PRICES 
SECTION  F  -  DESCRIPTION/SPECIFICATIONS 
SECTION  G  -  PRESERVATION/PACKAGING/PACKING 
SECTION  H  -  DELIVERIES  OR  PERFORMANCE 
SECTION  I  -  INSPECTION  AND  ACCEPTANCE 
SECTION  J  -  SPECIAL  PROVISIONS 
SECTION  K  -  CONTRACT  ADMINISTRATION  DATA 

UCF  AND  RFP  PART  III  -  GENERAL  PROVISIONS 

SECTION  L  -  GENERAL  PROVISIONS 

UCF  AND  RFP  PART  IV  -  LIST  OF  DOCUMENTS 
AND  ATTACHMENTS 


SECTION  M  -  LIST  OF  DOCUMENTS, EXHIBITS,  AND  OTHER 
ATTACHMENTS 

Figure  5-1.  RFP  Outline  in  Uniform  Contract  Format 
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5.2.2  RFP  Model  Contract 


RFP  Part  II  -  The  Schedule,  Part  III  -  General  Provisions,  and 
Part  IV  -  List  of  Documents  and  Attachments  serve  as  a  Model  Contract. 
They  consist  of  a  description  of  the  supplies  and  services  to  be  provided 
by  the  contractor,  the  Delivery  Schedule,  the  Contract  Terms  and  Con¬ 
ditions,  Contract  Administration  Data  and  a  list  of  documents  and 
attachments  thereto.  Basically,  the  Model  Contract  is  the  Government's 
initial  contract  proposal.  It  contains  numerous  blanks  for  the  offerors 
to  complete  and  is  subject  to  change  during  the  negotiations  that  are 
later  conducted  with  each  qualifying  offeror. 

AFR  70-15  mandates  inclusion  of  a  Model  Contract  in  a  Validation 
Phase  or  Full-Scale  Engineering  Development  Phase  RFP.  Such  inclusion 
is  intended  to  limit  negotiation  to  possible  alteration  of  specific  Model 
Contract  Provisions.  Use  of  a  largely  standard  contract  based  on  the  Model 
Contract  can  also  assure  appropriate  and  consistent  contractual  pro¬ 
visions  governing  issues  common  to  many  Major  Defense  System 
acquisition  programs. 

5.2.3  RFP  Attachments 

The  RFP  attachments  normally  include  the  Statement  of  Work  (SOW), 
Specifications,  appropriate  Project  Summary  Work  Breakdown  Structures 
(WBS),  Preliminary  Contract  Work  Breakdown  Structure  (CWBS)  and 
their  Dictionaries,  applicable  engineering  drawings,  DDForm  254  (Contract 
Security  Classification  Specification) ,  enforceable  contractor-prepared 
plans,  a  Contract  Data  Requirements  List  (CDRL),  and  other  documents 
which  provide  information  essential  to  the  particular  contract.  Copies 
of  modified  or  Unique  Data  Item  Descriptions  (UDID's)  referenced  in 
CDRL's  will  be  included  in  this  part  as  annexes  to  the  CDRL. 

5.2.4  RFP  Classified  Parts 

Classified  information  pertinent  to  the  RFP  may  be  placed  in  a 
separate  RFP  volume,  if  desired. 

5.3  RFP  EVENTS  AND  SCHEDULES 

Individuals  preparing  the  RFP  should  become  familiar  with  the 
program  objectives,  direction,  and  guidance  to  identify  the  few  truly 
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firm  requirements  by  reviewing  the  program  background  documents, 
the  DCP  i  ssues  resolved  by  the  Defense  System  Acquisition  Review 
Council  (DSARC)  Program  Memorandum,  the  PMD,  the  PP,  the  PMP,  or 
other  direction  and  guidance  documents.  In  addition,  they  should  identify 
goals  or  desired  capabilities  and,  if  feasible,  arrange  them  in  order  of 
priority.  These  should  not  be  confused  or  intermixed  with  the  firm 
requirements. 

Along  with  local  directives  on  RFP  and  SOW  preparation,  the 
following  documents  should  also  be  reviewed  before  RFP  preparation 
is  started. 

•  AFSCP  800-6,  "SOW  Preparation  Guide" 

•  AFSCP  70-4,  "RFP  Preparation  Guide" 

•  AFSCM  173-4,  "Program  Breakdown  Structures  and  Codes" 

•  MIL-STD-881  A,  "Work  Breakdown  Structures  for  Defense 

Materiel  Items" 

•  AFR-310-1,  "Management  of  Contractor  Data" 

•  AFR-800-14,  Vol  II,  "Acquisition  and  Support  Procedures 

for  Computer  Resources  in  Systems" 

5.3.1  Planning 

Preparing  an  RFP  for  a  major  program  can  be  a  lengthy  task. 
Events  should  be  scheduled  in  advance.  Figure  5-2  presents  a  typical 
procurement  planning  schedule  requiring  over  one  year  to  complete. 

Since  no  RFP  is  self-explanatory,  it  is  advisable  to  have  maximum 
face-to-face  interchange  with  industry  to  insure  they  understand  the 
requirements,  constraints,  intentions,  etc.  This  makes  industry  work 
toward  what  you  really  want,  encourages  more  bidders,  helps  form 
stronger  teams,  and  gets  corporate  commitment.  It  also  helps  industry 
believe  you  really  want  comments  on  DRFP's,  not  just  cosmetic 
motherhood . 

At  the  optional  meeting  with  industry  in  Figure  5-2,  the  system 
level  requirements  should  be  explained  with  the  issuance  of  a  first  cut 
system  specification.  This  meeting  may  also  be  used  to  discuss  lower 
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Figure  5-2.  Typical  Procurement  Planning  Schedule 


specifications,  SOW,  data  requirements,  logistics,  etc.  This  meeting 
with  industry  gives  industry  an  extra  look  at  requirements  and  a  chance  to 
see  how  you  incorporated  their  comments  in  the  draft  RFP.  The  Program 
Office  can  also  take  advantage  of  the  informal  discourse  with  industry  at 
these  early  stages  to  build  a  better  acquisition. 

5.3.2  Draft  Requests  for  Proposals 

AFR's  70-15  and  800-25  require  that  solicitations  on  procurements, 
that  have  the  potential  for  significant  industry  cost  reductions,  provide 
for  feedback  from  prospective  contractors  regarding  performance, 
schedules  and/or  other  contractual  requirements  which,  if  changed, 
would  reduce  needless  cost  and/or  improve  the  acquisition.  AFR  70-15 
contains  procedures  to  be  followed  on  major  system  acquisitions.  AFSC 
and  local  ASPR  Supplements  contain  procedures  for  acquiring  industry 
feedback  on  other  draft  solicitations.  The  DRFP  review  by  industry  may 
be  solicited  before  receipt  of  a  formally  approved  Secretarial  D&F  and 
may  be  effected  either  in  full  with  a  draft  of  the  complete  solicitation  or 
in  part  with  a  draft  of  one  or  more  sections  of  the  RFP.  Partial  release 
of  the  DRFP  (for  example,  only  the  Statement  of  Work,  specifications, 
standards,  CDRL,  and  RFP  Sections  C  and  D)  can  be  accomplished  while 
other  portions  of  the  solicitation  are  being  prepared  to  minimize  and 
avoid  the  loss  of  procurement  leadtime.  The  DRFP  is  accompanied  by 
an  Executive  Summary  letter  and  contains  the  elements  prescribed  in 
AFSC  ASPR  Sup  3-550  (c)  2. 

5.3.3  Procurement  Evaluation  Panels 

AFSCR  70-7  requires  the  use  of  procurement  evaluation  panels 
(called  Murder  Boards)  on  selected  major  procurements  to  evaluate  the 
completeness,  clarity,  and  accuracy  of  solicitations  before  their  release 
to  industry.  Specifically,  panel  review  is  required  for  programs  on 
which  the  Secretary  of  the  Air  Force  is  the  source  selection  authority 
(AFR's  70-15  and  800-2),  other  major,  high-interest  programs,  and, 
by  local  directive,  to  lesser  programs.  The  value  of  procurement 
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evaluation  panels  has  been  demonstrated  by  the  measurable  improvement 
in  the  quality  of  RFP's.  Field  command  panel  reviews  assist  greatly  in 
improving  the  quality  of  RFP's. 

5.3.4  Other  RFP  Reviews 

Other  commands  and  agencies  participating  in  the  program  (ATC, 
AFLC,  Using  Command)  should  be  contacted  to  obtain  "sign-off1  on  their 
requirements.  If  the  above  Procurement  Evaluation  Panel  (AF’SCR  70-7, 
Murder  Board)  is  used,  participation  by  these  other  commands  and 
agencies  provides  an  excellent  vehicle  for  this  step.  The  evaluation  pro¬ 
vides  a  final  opportunity  to  ensure  compliance  with  current  procurement 
policy,  to  review  technical  requirements,  and  to  ensure  RFP  language 
reflects  program  objectives. 

The  Technical  Requirements  and  Standards  Group  provides  certifi¬ 
cation  that  the  final  SOW  has  been  reviewed  by  interested  offices  of 
prima ry/functional  responsibility  and  is  proper  for  inclusion  in  the  contract. 

Staff  offices,  such  as  the  procurement  committee  and  judge  advocate, 
review  the  RFP  package  to  ensure  compliance  with  current  regulations, 
policy  and  directives. 

Where  system  source  selection  procedures  are  to  be  used,  the 
Source  Selection  Board  should  also  review  and  approve  RFP  package.  This 
review  can  elicit  suggestions  for  improvements  which  may  avoid  costly 
and  time-consuming  problems  during  source  selection  and  contract 
negotiations  . 

5.4  PRODUCING  THE  RFP 

For  competitive  procurements  the  buying  offices: 

1  .  Prepare  RFP's  IAW  ASPR  3-500  and  AFR  70-15  and  supple¬ 
ments  and  ASPR  requirements.  Since  each  procurement  has 
characteristics  of  its  own  which  warrant  treatment  of  RFP 
provisions  different  from  any  other  RFP,  no  sample  solicita¬ 
tion  is  provided.  Each  specific  procurement  will  have  unique 
Sections  C&D  although  form  and  format  will  normally  be 
standardized  locally.  Sections  C-2  and  D  apply  only  to 
competitive  procurements. 
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2. 


Forward  each  competitive  RFP  to  the  prospective  offerors 
under  a  brief  and  concise  "Executive  Management  Summary" 
letter.  Representative  contents  for  this  letter  are  provided 
in  AFSCP  70-4,  Section  3-10.  It  is  signed  by  the  program 
director/project  manager,  the  PCO  or  higher  level  depending 
on  program  impoitance.  Ihis  letter  provides  industry  and 
government  top  management  with  a  summary  of  the  salient 
features  of  the  procurement. 

For  follow-on  and  single  source  procurements  the  buying  offices: 

1*  Tailor  the  letter  of  transmittal  to  the  specific  requirement 
instead  of  forwarding  the  RFP  as  in  (2)  above. 

2.  Provide,  where  necessary,  proposal  preparation  instructions 
similar  to  that  specified  in  5. 4. 1.3. 2  below. 

3.  Adhere  to  guidance  contained  in  5.4.2  below. 

5.4.1  RFP  Part  I  -  General  Instructions 

Instructions  for  Proposal  Preparation  (IFPP)  are  contained  in  UCF 
Part  I  -  General  Instructions,  Sections  A  through  D.  Each 'of  these 
sections  is  covered  below. 

5.4. 1.1  Section  A  -  Cover  Sheet  (DP  Form  1707) 

This  RFP  section,  corresponding  to  UCF  Section  A,  contains 
information  such  as  the  name  and  identification  number  assigned  to  the 
potential  contract,  the  issuing  Government  office,  and  the  Government' s 
official  point  of  contact  with  bidders. 

This  section  also  contains  a  separate  table  of  contents  for  Parts  I 
through  IV  of  the  RFP. 

5.4. 1.2  Section  B  -  Contract  Forms  and  Representations,  Certification 
and  Other  Statements  of  Offerors 

This  RFP  section,  corresponding  to  UCF  Section  Ft,  consists 
principally  of  the  Solicitation,  Offer  and  Award  (Standard  Form  33)  plus 
supplementary  material.  It  identifies  all  parts  of  the  RFP,  specifies 
terms  for  delivery  of  the  proposal,  and  contains  a  number  of  questions 
pertinent  to  the  Source-Selection  to  be  answered  by  each  bidder. 


-43- 


There  are  no  software  representations  or  certifications  required  or 
recommended  in  ASPR.  However,  certain  AFSC  product  divisions  have 
required  offerors  to  certify  whether  or  not  they  have  developed,  generated, 
delivered  or  are  obligated  to  deliver  the  same  or  substantially  the  same 
computer  software  included  in  their  offer. 

5.4.  1  .  3  Section  C  -  Solicitation  Instructions  and  Conditions,  and  Notices 
to  Offerors  and  Proposal  Preparation  Instructions 

This  RFP  section  is  comprised  of  ASPR  Standard  Form  33A  plus 
supplementary  material  prescribed  in  ASPR  3-  501  (b)  Section  C  and 
ASPR  9-202.2.  It  corresponds  to  UC.F  Section  C. 

5.4.1.  3.1  Section  C-l  -  Instructions  and  Conditions,  and  Notices 
to  Offerors .  Typical  software  related  clauses  for  inclusion  in  this 
section  are: 

1.  ''Identification  of  Restricted  Rights  Computer  Software" 
provision  in  7-2003.76  to  be  inserted  in  accordanc'e  with 
ASPR  9  -603(b) .  (Ref.  ASPR  3-501(b)  Section  C  (liv) ) . 

2.  Some  provision  for  predetermination  of  rights  in 
technical  data  and  computer  software  (Ref.  ASPR  9-202.  2(d) 
Note  that  no  ASPR  provision  exists  for  this  important  solici¬ 
tation  task.  AFSC  ASPR  Sup  7-2003.61  contains  a  pro¬ 
vision  which,  if  tailored  for  a  particular  solicitation,  is  a 
step  in  the  right  direction.  However,  particular  care  and 
effort  should  be  taken  in  coordination  with  legal,  procure¬ 
ment  and  technical  personnel  to  insure  that  appropriate 
rights  in  critical  software  or  technical  data  (or  options  for 
those  rights)  are  obtained.  This  can  only  be  accomplished 
if  time  is  taken  to  draft  an  RFP  provision  and  to  include 

an  implementing  agreement  in  the  resulting  contract. 

(See  AFR  800-14  Vol.  1,  AFSC  Sup  1). 

5 . 4 . 1 . 3 . 2  Section  C-2  -  Proposal  Preparation  Instruction.  Thi s 
section  provides  specific  guidance  on  proposal  preparation  (technical, 
management,  and  cost/price  proposals  and  format).  By  including 
instructions  in  this  section,  the  RFP  preparation  team  will  insure  that 
offerors  will  place  appropriate  emphasis  on  software  development  and 
management.  Instructions  should  touch  on  such  areas  as  configuration 
management,  data  management,  cost  management  and  software  develop¬ 
ment  (e.g.,  analysis,  design,  code  and  checkout,  debug  and  levels  of 
test  and  integration)  for  operational  and  support  software. 
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RFP's  Bhould  require  offerors  to  submit  a  great  deal  of  this 
information  formatted  as  a  Computer  Program  Development  Plan  (CPDP) 
(See  AFR  800-14,  Vol  II,  paragraph  3-9  and  DI-S-30567A)  that  is 
tailored  to  specific  requirements  of  the  acquisition,  )  The  CPDP  can  be 
the  initial  submittal  of  a  CDRL  requirement  that  will  be  subsequently 
updated  once  on  contract. 

The  RFP  should  identify  any  non-obvious  technical  risks.  Bidders 
should  also  be  asked  to  identify  critical  factors  in  their  proposals. 
Currently,  the  following  are  likely  to  be  among  the  set  of  high-risk  soft¬ 
ware  capabilities: 

1.  C ertifiably  correct  control  of  access  to  data  of  different 
security  classifications  and  in  different  "need  to  know" 
categories; 

2.  Automatic  detection  and  correct  reporting  of  equipment 
and  software  errors; 

3.  Automatic  reconfiguration  and  recovery  of  the  system 
from  errors,  including  transition  to  and  from  degraded 
modes  of  operation; 

4.  Single  point  failure  elimination; 

5.  Reaction  time  to  threats; 

6.  Redundancy  for  critical  mission  functions; 

7.  Radiation  hardening  methods; 

8.  Multi-mission  design, 

5,4, 1.4  Section  D  -  Evaluation  Factors  for  Award 

This  RFP  section,  corresponding  to  UCF  Section  D,  should  state 
in  general  terms  the  criteria  the  Government  plans  to  use  to  evaluate 
the  proposals,  and  the  relative  importance  of  each  aspect  of  the 
proposal  (e.  g.  ,  cost,  technical,  management).  The  evaluation  criteria 
should  include  consideration  of  critical  factors  and  of  high-risk  proposal 
provisions . 

The  RFP  should  also  state  the  importance  to  evaluation  of  factors 
extraneous  to  the  proposal  itself,  e.g.  ,  exceptions  to  the  terms  and 
conditions  of  the  RFP,  alternatives  to  the  government's  requirements, 
energy  conservation,  other  salient  factors. 
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Neither  the  detailed  evaluation  criteria  to  be  applied  by  the  SSEB, 
nor  the  exact  weights  to  be  attached  to  each  criterion  by  the  SSAC  should 
be  revealed  to  bidders.  Nevertheless,  the  RFP's  evaluation  criteria 
should  be  as  informative  as  possible,  in  order  to  elicit  the  best  possible 
proposals,  to  minimize  misunderstandings,  and  to  avoid  claims  by  losing 
bidders  that  their  proposals  were  treated  unfairly.  The  guidebook  in 
this  series  on  Contracting  for  Software  Acquisition  discusses  detailed 
evaluation  criteria. 

5.4.2  RFP  Parts  II-IV  -  Model  Contract 

RFP  Part  II  -  The  Schedule,  Part  III  -  General  Provisions,  and 
Part  IV  -  List  of  Documents  and  Attachments  serve  as  a  Model  Contract 
in  the  RFP.  RFP  Parts  II,  III,  and  IV  consist  of  UCF  Sections  E  through 
K,  L,  and  M,  respectively,  as  shown  in  Figure  5-1.  Subsequent  sub¬ 
sections  discuss  those  software-related  items  relevant  to  preparation 
of  these  RFP  parts.  Review  of  ASPR  3-501,  and  of  an  actual  contract 
for  a  Major  Defense  System  or  a  Segment  of  one,  is  recommended  prior 
to  RFP  preparation. 

5.4.2.  1  Section  E  -  Supplies/Serviccs,  and  Prices 

This  section  of  the  Model  Contract  part  of  the  RFP  (UCF  Section  E) 
lists  the  major  groups  of  supplies  and  services  to  be  provided  under  the 
contract.  Each  such  group  is  termed  a  Contract  Line  Item  (CLI)  and  is 
represented  by  a  unique  Contract  Line  Item  Number  (CLIN)  (e.g.,  0001, 
0002).  Some  Contract  Line  Items  are  broken  down  into  major  parts  called 
Subline  Items,  each  with  a  sub-CLIN  (e.g.,  0002AA,  0002AB),  the  latter 
clearly  related  to  those  of  the  Contract  Line  Items  to  which  they  belong. 
Section  E  includes  a  quan.Uy,  and  or  cost  and  fee  for  cost  reimbursable 
contracts  or  a  target  prii  <.  .or  each  sub-CLIN  and  for  each  CLIN  that 
has  no  sub-CLIN.  The  prices,  or  costs  and  fees,  agreed  on  during 
negotiation  become  part  of  the  negotiated  contract's  Section  E.  Each 
CLIN  should  correspond  to  some  SOW  paragraph(s)  and  some  Preliminary 
CWBS  Element(s)  (see  Section  3.4.2).  ASPR's  3-501  and  20-  300  apply. 

A  CLI  should  be  included  to  refer  to  the  CDRL  (i.  e.  ,  the  deliverable 
technical  data)  (ASPR  3  -  501(D)  Section  E). 
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5 . 4 . 2  .  1 .  1  Software  Cl  Version  Definition.  Define  a  s epa  rate  (or  sub 
CLIN)  for  each  version  of  a  software  Cl  where  different  delivery/ 
acceptance  requirements  apply.  Include  instructions  in  the  Delivery 
Schedule  (see  Section  5. 4. 2.  3  below)  prescribing  the  number  of  versions 
of  each  software  Cl  and  the  terms  of  these  versions'  delivery  during  a 
single  Period  of  Performance.  Insure  requirements  for  delivery  to 
IV&V  contractor,  government,  etc.  are  included  as  necessary. 

5.4.2. 1.2  Dual  Identification  of  Software.  Besides  identification  a  s  a 
CLIN,  each  deliverable  software  Cl  must  also  be  represented  by  a  DD 
Form  1423  entry  (ASPR  9-603(a)  and  AFSC  supplement).  This  require¬ 
ment  is  meant  to  satisfy  an  ASPR  definition  of  software  as  data.  A 
special  annex  or  attachment  should  be  setup  for  this  purpose.  It  should 
contain  a  separate  DD142  3  entry  for  each  deliverable  CPCI.  Each  such 
entry  must  reference  the  contract  schedule  for  delivery  requirements. 

Cost  for  each  entry  will  be  levied  against  the  applicable  CLIN.  Note  that 
CPCI  documentation  will  not  be  included  in  the  Special  Annex/Attachment. 

It  should  be  included  in  the  CDRL  with  all  other  technical  data.  See 
Section  3.4  4.2  for  an  explanation  of  this  treatment. 

5.4. 2. 2  Section  F  -  Description/Specifications  and  Section  G  - 
Packaging  and  Marking 

RFP  Section  F  of  the  Model  Contract  is  not  used  when  a  SOW  is 
included  a  s  an  attachment  to  the  RFP  and  is  incorporated  in  Section  E 
of  the  contract  by  reference.  Use  this  section  only  when  warranted. 

ASPR  3-501  recommends  its  use  when  Section  E  is  not  in  sufficient 
detail  to  describe  the  CLI's.  Basic  guidance  on  content  is  contained 
in  ASPR  1-1200. 

5.4. 2. 3  Section  H  -  Deliveries  or  Performance 

This  section  of  the  Model  Contract  part  of  the  RFP  (UCF  Section  H) 
prescribes  for  each  CLIN  a  desired  delivery  date  or  Period  of  Performance. 
Section  H  is  often  called  the  Delivery  Schedule.  The  Delivery  Schedule 
can  be  a  major  item  during  negotiation  and  will  become  contractually 
binding  on  the  winning  bidder.  Therefore  realistic  schedules  for  the 
software  development  should  be  included  here. 
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A  Period  of  Performance  can  be  defined  to  begin  or  to  end  either 
at  a  fixed  date  or  relative  to  the  completion  of  some  other  CLIN's  Period 
of  Performance  or  delivery  date.  Similarly,  its  duration  can  either  be 
fixed  (e.g.  ,  six  months)  or  can  depend  on  other  CLIN's.  All  relative 
dates,  however,  must  be  related  to  a  fixed  calendar  date. 

Groups  of  supplies  and  services  wanted  at  different  times  should 
normally  be  defined  as  separate  CLIN's  (or  Sub-CLIN's)  in  Section  E 
of  the  RI-  P  (see  Section  5 . 4 . 2 . 1  above) .  To  avoid  possible  incon  si  stency , 
SOW  definitions  of  tasks  should  reference  the  Delivery  Schedule  rather 
than  incorporate  delivery  dates  and  Periods  of  Performance. 

5. 4. 2. 4  Section  I  -  Inspection  and  Acceptance 

This  section  of  the  Model  Contract  part  of  the  IlFP  (UCF  Section  I) 
should  include  the  place  of  inspection  and  place  of  acceptance  of  the 
CLIN’s.  ( ASPR  14-300). 

5.4.2.  5  Section  J  -  Special  Provisions 

This  section  of  the  Model  Contract  part  of  the  RFP  (UCF  Section  J) 
typically  contains  miscellaneous  definitions,  clarifications,  and  other 
items  that  would  fit  poorly  elsewhere.  Among  the  most  important  pro¬ 
visions  typically  incorporated  are:  definition  of  the  type  of  contract  (e.  g. 
CPIF ,  CPFF),  incentive  arrangements,  contractor  use  of  GFP,  definition 
of  relationships  among  Government  participants  and  contractors,  and 
data  rights  agreements.  If  any  of  these  topics  is  fully  covered  by  a 
standard  clause,  it  will  be  treated  under  General  Provisions  (see 
Section  5.4.2. 7  below)  instead  of  Special  Provisions. 

5. 4. 2. 5.1  GFP.  The  GFP  provisions  should  identify  all  items  of  GFP 
(including  Government-furnished  software  or  computer  time)  to  be  used 
by  the  contractor  as  development  aids  or  with  which  equipment  or  soft¬ 
ware  to  be  developed  under  the  contract  must  interface.  The  GFP  pro¬ 
visions  should  also  specify  the  pertinent  documentation  to  be  made 
available  and  state  when,  where  and  under  what  conditions  the  contractor 
can  use  each  GFP  item.  For  example,  a  Government-owned  operating 
system  would  normally  be  listed  among  the  GFP  with  which  contractor- 
developed  application  software  would  interface,  unless  the  acquisition 
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included  development  of  the  operating  system.  Great  care  should  be 
taken  to  identify  GFP  precisely,  and  to  define  correctly  the  RFP's  inter¬ 
faces  with  equipment  or  software  to  he  developed  under  the  contract. 
Otherwise,  the  errors  and  omissions  in  GFP  definition  may  be  cause 
for  an  equitable  adjustment  in  the  price,  terms  or  conditions  of  the  contract. 

5.4.2.  5.2  Working  Relationships.  If  the  a  cqui  sit  ion  involves  two  or  more 
contractors  who  must  interface  their  products  or  tasks,  the  Special  Pro¬ 
visions  should  define  their  working  relationships.  Similarly,  if  Govern¬ 
ment  contract  management  includes  an  SE/TD  contractor  or  independent 
V&V  contractor /agency,  these  require  special  definitions  in  the  Special 
Provisions  which  should  specify  the  relationships  including  subcontractors 
as  well.  Finally,  if  the  contract  involves  subcontracting,  the  Special 
Provisions  should  direct  Government  visibility  (vs.  control)  into  the  sub¬ 
contractors'  activities.  For  example,  the  Special  Provisions  should 
insure  that  prime  contractors  notify  the  Government  of  important 
subcontractor  meetings,  (e.g.,  PDR's,  CDR's).  They  should  grant 
the  Government  the  right  to  attend  all  such  meetings.  They  may  also 
specify  direct  subcontractor  delivery  to  the  Government  of  copies  of  all 
subcontractor-produced  documents  deliverable  to  the  prime  contractor. 

5.4. 2.  5.  3  Government  Rights  to  Data.  Inadequate  provisions  for 
Government  rights  to  software  and  technical  data  produced  under  a 
contract  have  caused  trouble  and  expense  in  several  acquisitions.  As 
a  rule,  the  contract  should  grant  the  Government  sufficient  rights  (or 
options  for  rights)  in  software  and  technical  data  developed,  generated, 
used  or  delivered  under  the  contract  to  insure  its  ability  to  operate,  test, 
and  maintain  the  system  as  planned  and  as  offered  by  the  contractor. 

In  order  to  do  this,  every  effort  should  be  made  to  predetermine 
rights  to  technical  data  and  computer  software  prior  to  contract  award 
or  early  enough  to  insure  satisfactory  resolution  that  performance  will 
not  be  inhibited.  The  agreement  should  pertain  to  technical  data  and 
computer  software  that  will  be  developed,  generated,  used,  modified 
or  deliverable  under  the  contract  and  that  is  necessary  to  operate,  test 
and  maintain  the  system  as  planned  and  as  offered  by  the  contractor. 

It  should  require:  1)  identification  of  the  data  and  software,  2)  statement 
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of  a  price  to  obtain  unlimited  rights  or  a  license,  if  either  is  offered, 

3)  the  time  required  for  delivery  if  optioned,  4)  the  current  status  of 
the  Governments's  rights  (e.g.,  limited  rights,  restricted  rights, 
license,  none)  and  5)  that,  if  the  identified  list  changes  during  the  per¬ 
formance  of  the  contract,  the  PCO  must  be  promptly  notified  and  the 
predetermination  updated  if  deemed  appropriate. 

It  may  also  be  advisable  to  obtain  an  agreement  whereby  the  prime 
contractor  will  provide  technical  assistance  to  make  the  software, 
procured  under  the  Predetermination  Agreement,  work  at  other  facilities 
where  computers,  processes,  etc.  are  different,  causing  the  software  not 
to  work.  The  government,  however,  must  bear  the  cost  of  the  technical 
assistance,  if  the  option  is  exercised. 

5.4.2. 6  Section  K  -  Contract  Administration  Data 

This  section  is  identified  in  the  RFP  in  order  to  form  the  basis 
for  insertion  of  the  proper  information  in  the  resulting  contract. 

5.4. 2.  7  Section  L  -  General  Provisions 

This  section  of  the  Model  Contract  part  of  the  RFP  (UCF  Section  L) 
typically  lists  the  standard  ASPR  contract  clauses  incorporated  by 
reference  in  the  Model  Contract,  e.g.,  7-104. 9(a)  and  (b)  "Rights  in 
Technical  Data  and  Computer  Software"  and  7-104.  9(m)  "Deferred 
Ordering  of  Technical  Data  or  Computer  Software"  ,  The  General  Pro¬ 
visions  may  also  include  other  Departmental,  Command  or  local  standard 
clauses,  e.g.,  Restrictions  on  Printing,  Release  of  Information,  as 
required. 

5 . 4 . 2 . 8  Section  M  -  List  of  Documents,  Exhibits,  and  Other  Attachments 

This  section  of  the  Model  Contract  Part  of  the  RFP  is  a  list  of 
attached  documents  and  references  which  should  include  as  a  minimum 
the  SOW,  the  CDRL,  and  DD  Form  254  (Contract  Security  Classification 
Specification)  but  may  also  include  the  specifications,  the  appropriate 
Project  Summary  WBS  or  Summary  PBS,  the  Preliminary  CWBS,  their 
Dictionaries,  any  applicable  Engineering  Drawings,  and  any  other  docu¬ 
ments  that  provide  background  information  essential  to  the  particular 
contract,  See  ASPR  3-501  for  guidance. 
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As  a  rule,  the  list  should  include  every  document,  incorporated 
by  reference  in  the  Model  Contract,  which  a  bidder  may  be  presumed 
not  to  possess.  Whenever  the  RFP  omits  such  a  document,  bidders 
should  be  given  rapid  access  to  it  on  request,  subject  to  compliance  with 
security  regulations. 

5.4.3  RFP  Attachments 

Sections  5.4.  3.1  -  5.4.  3. 5  respectively,  discuss  the  Specifications, 
Engineering  Drawings,  DD  Form  254,  WBS,  and  CDRL. 

5.4.3. 1  The  Specifications 

The  Specifications  define  the  system  and  its  parts.  Thus,  the 
Specifications  are  an  essential  part  of  an  RFP  for  a  contract  that 
includes  software  development,  since  the  effort  contracted  for  is  best 
defined  relative  to  Specification  provisions. 

A  RFP  may  include  software- related  specifications  of  several 
levels  and  types,  depending  on  the  contractual  approach,  on  the  acquisition 
Life  Cycle  Phase,  and  on  the  types  of  work  and  product  being  contracted 
for.  See  Table  1-1.  These  different  kinds  of  specifications  are  discussed 
in  the  Documentation  Guidebook  in  this  series. 

The  RFP  for  a  Conceptual  Phase  contract  to  define  a  Major  Defense 
System  cannot  normally  include  a  System  Specification  since  an  Initial 
System  Specification  is  the  usual  product  of  such  a  contract.  However, 
the  RFP  should  incorporate  any  documents  that  prescribe  system 
requirements  or  suggest  potentially  feasible  designs,  as  direction  to  or 
guidance  for  the  contractor.  Such  documents  include  any  appropriate 
ROC,  plus  specifications  for  analogous  systems,  for  interfacing  systems, 
and  for  any  subsystems  that  the  system  to  be  defined  must  incorporate. 

In  contrast,  an  RFP  for  a  contract  to  provide  deliverable,  end 
product  software  during  any  single  phase  of  the  overall  weapon  system 
development,  even  conceptual  phase,  should  definitely  include  either: 

1.  Provisions  for  a  contractual  milestone,  such  as  a  software 
PDR,  at  which  to  authenticate  the  contractor -developed 
specification,  or 

2.  The  specification  itself. 
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A  Validation  Phase  contract  RFP  should  include  the  Initial  System 
Specification,  augmented  by  any  other  documents  that  modify  the  system’s 
requirements.  In  particular,  the  Specifications  should  include  specifi¬ 
cations  of  interfacing  systems  and  of  any  subsystems  whose  inclusion 
in  the  planned  system  is  directed. 

The  RFP(s)  for  Full-Scale  Engineering  Development  contracts 
should  include  a  subset  of  the  Allocated  Baseline  developed  during  the 
Validation  Phase.  This  subset  should  comprise  the  Authenticated  S,  .em 
Specification;  any  appropriate  Segment  Specification,  a  Computer  Program 
Development  Specification  for  each  software  CPCI  to  be  developed  under 
the  contract,  and  appropriate  specifications  for  the  software  CPCI's, 
any  other  Segments,  and  any  other  systems,  with  which  the  software  to 
be  developed  under  the  contract  must  interface. 

Software- related  Production  Phase  and  Deployment  Phase  RFP's 
should  each  incorporate  the  latest  approved  versions  of  each  of  the 
System  Specifications,  any  relevant  Segment  Specifications,  all  software 
CPCI  Development  and  Product  Sepcifications,  and  analogous  equipment 
specifications,  pertinent  to  the  Software  maintenance,  modification,  or 
related  development  planned. 

One  General  policy  is  recommended:  don't  allow  substantial 
software  development  effort  to  commence  without  sufficient,  clear. 
Development  Specifications  that  incorporate  a  complete  and  validated 
requirements  set.  Whenever  such  specifications  are  missing,  incomplete, 
internally  inconsistent,  in  conflict  with  other  known  requirements,  or 
inadequately  validated,  software  development  is  premature.  Before  a 
software  development  contract  is  let,  further  effort  (perhaps  itself 
contracted  for)  should  rectify  the  deficiencies,  possibly  even  if  schedules 
thereby  slip.  Failure  to  follow  the  recommended  procedure  has  led  to 
an  inefficient  software  development  process  that  sometimes  has  caused 
serious  cost  overruns  and  schedule  slips  in  the  systems  that  included 
this  software.  The  costs  of  sound  specification  are  usually  repaid  with 
interest  in  problems  avoided  later. 
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5. 4. 2. 3  Engineering  Drawings 


These  typically  describe  equipment  ( e.  g. ,  a  computer-to-computer 
interface)  or  a  vehicle  (e.  g. ,  vehicle  equipment  layout,  a  computer 
installation).  Such  Engineering  Drawings  may  be  necessary  for  the  develop¬ 
ment  of  software  that  must  interface  with  such  equipment  or  the  persons 
operating  it. 

5.4. 3. 3  Contract  Security  Classification  Specification 

This,  consisting  of  DD  Form  254  plus  possible  attachments,  states 
the  security  requirements  applicable  to  the  contract.  For  example,  it 
prescribes  the  level(s)  of  security  clearance  required  of  contractor 
personnel  working  on  the  contract  and  the  criteria  for  classifying  contract 
generated  information. 

5.4.  3.4  Work  Breakdown  Structure  (WBS) 

MIL-STD-881A  prescribes  preparation  of  several  types  of  WBS 
during  planning  for  acquisition  of  Major  Defense  Systems  and  many  less- 
than-major  systems.  AFSCM  173-4,  Program  Breakdown  Structure  and 
Codes,  supports  MIL-STD-881A  for  programs  managed  by  AFSC. 

Section  3.4.2  above  discusses  the  WBS  in  detail.  The  Project 
Summary  WBS,  the  CWBS,  and  their  Dictionaries  may  be  attachments 
to  the  RFP. 

5.4. 3. 5  CDRL 

The  CDRL  defines  the  documentation  and  the  software  storage  media 
deliverable  under  the  contract.  These  are  termed  Data  Items.  All 
instances  of  each  Data  Item  are  defined  in  a  sequence -numbered  CDRL 
entry.  Section  3.4.4  above  discusses  the  CDRL  preparation  in  detail. 

5.4.4  Classified  Parts  of  the  RFP 

Any  classified  attachments,  or  other  classified  provisions  of  the 
RFP,  may  be  contained  in  a  separate  volume  and  referenced  from  their 
usual  places.  For  example,  this  volume  might  contain  a  classified 
threat  model. 
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